How do we handle 'Unfinished User Stories' at the end of a Sprint in Scrum?

All answers to this question.

Extending a Sprint is a major anti-pattern; it destroys the "cadence" that Scrum relies on. If a story isn't "Done" according to your official criteria, it earns zero points for that Sprint. You must move the unfinished story back to the Product Backlog. The Product Owner then decides if it’s still a priority for the next Sprint. This provides a "Clean Mirror" of your team's actual velocity. If you count partial points, you are inflating your velocity and making future Sprint Planning inaccurate. Use the Retrospective to identify why the stories spilled—was the "Definition of Ready" too loose, or was the task breakdown not granular enough?

   Answered 2025-03-16 by Linda Thompson

Do you think that the pressure to reach a high "Velocity" is what's causing the team to over-commit and ignore the quality standards of the Definition of Done?

   Answered 2025-03-18 by Robert Miller

• You've hit on a common cultural issue, Robert. When Velocity is used as a "Performance Metric" rather than a "Planning Tool," teams start cutting corners. The Scrum Master needs to protect the team by explaining to leadership that a lower, stable velocity is much better for long-term product health than a high, erratic one. We should focus on "Outcome over Output." If the team stops worrying about the "Number" and starts focusing on the "Value" delivered in each increment, the quality naturally improves and the "spillover" rate usually drops.

     Commented 2025-03-20 by James Wilson

We started using "Story Pointing" more strictly during Refinement. If a story is bigger than an 8, we force a split. This drastically reduced our end-of-sprint spills.

   Answered 2025-03-22 by Michael Brown

• I agree with Michael. Small stories are the secret to a high success rate. Sarah, definitely hold firm on the "Zero Points" rule; it's the only way to stay honest with your data.

     Commented 2025-03-24 by Sarah Jenkins