Our team is consistently over-committing during Sprint Planning, and we end up with 20-30% of our story points rolling over to the next cycle. Is it better to extend the Sprint by a day to finish, or should we move everything back to the Product Backlog and reassess? Looking for Scrum Master best practices on maintaining a clean Velocity.
3 answers
Strictly following the Scrum Guide, you should never extend a Sprint. A Sprint is a time-boxed event, and the deadline is fixed to maintain a predictable cadence. Any unfinished items should return to the Product Backlog. During the Sprint Retrospective, your team needs to analyze why the over-commitment happened. Are the stories too large? Is there an "unplanned work" leak? Re-evaluating these items ensures that the Product Owner can re-prioritize them against new requirements. Carrying them over automatically inflates your next Sprint's workload and creates a cycle of failure that destroys team morale and predictable forecasting.
Kimberly, that is the textbook answer, but how do you handle the stakeholder pressure when a "must-have" feature isn't finished? If we move it back to the backlog and it doesn't get picked for the next Sprint, doesn't that create a trust gap with the business owners who were expecting a release?
We started using "yesterday's weather" for planning. We only commit to the average number of points we actually finished in the last three Sprints. It stopped the rollover issue almost immediately.
I agree with Jennifer. Looking at historical data rather than "ideal capacity" is the most honest way to plan. It forces the team to be realistic about their actual output.
David, that’s where the Product Owner’s role is vital. You have to explain that a "half-baked" feature is a technical risk. It is better to deliver a smaller, fully functional increment than a buggy one just to meet a date. Transparency during the Sprint Review is key; show them what was finished and explain the plan for the remaining items. This builds long-term trust through honesty.