What we should do if we run out of stories during sprint (e.g we are still learning what is our true velocity)? Can programmers pick some unscheduled bugs to fix or should we end sprint prematurely?

What if one person still is working on his task when all others already finished? Should they all help to finish that story or try to fill up time with some techical tasks (try to reduce technical debt)?

3 Answers 3



Scrum doesn't enforce batch sizes on stories the way some other methodologies do, so individual story sizes can vary dramatically. The important thing is that the aggregate of all stories should fit within the defined Sprint length, and the team is expected to adjust its processes as needed to optimize both estimation and Sprint Goal completion.

In practice, this means some stories will finish earlier than others; that is expected. When all stories are routinely finished early, that is a process issue that should be addressed in a systematic way.

When ALL Stories Are Finished Early

If your team has finished all stories before the expiration of the time box defined by the Sprint, the team is encouraged to work with the Product Owner to select additional stories off the top of the Product Backlog that may fit within the time remaining.

There are a few considerations here:

  1. Additional stories picked from the Product Backlog should be near the top in order to respect prioritization of the backlog, but must be selected for size rather than in strict priority order. That's why this requires the cooperation of the Product Owner, so that Product Backlog items can be reordered on the fly.
  2. These stories should ideally be related to the current Sprint Goal, but failure to complete "bonus work" must not compromise the current Sprint or prevent the achievement of the original Sprint Goal.
  3. If your team routinely finds itself with large blocks of slack in each Sprint, then you need to address the accuracy of your estimation process during the Sprint Retrospective, or be less conservative during Sprint Planning.
  4. Small blocks of slack are necessary and desirable. Scrum is not about 100% utilization; it is about visibility and transparency of the iterative process. If nothing else, these small blocks of extra time offer opportunities to refactor code, improve tests, perform additional code reviews, and so on. Whether these tech debt stories are added to the Sprint Backlog or the Product Backlog, the essential activity is to ensure that this work (and its value to the team or project) is made visible.

Teams should strive to optimize their efficiency, not maximize their utilization. That means that constructive use of slack time is a necessary part of sustainable development. Finding the correct balance that optimizes team velocity without imposing an unsustainable reduction in necessary slack time is part of the inspect-and-adapt process. Your Sprint Retrospectives are a great time to evaluate that balance on a routine basis.

When SOME Stories Are Finished Early

This is actually a common occurrence. While all user stories in a Sprint should be closely related to the Sprint Goal, they shouldn't be so interdependent that no stories can be completed unless they all are. Each story will be considered done or not-done independently, even if the story itself has another story as a prerequisite.

Because some stories are smaller and/or easier than others, some will be finished sooner. That's why agile frameworks encourage collective story ownership: even though one person may take responsibility for shepherding a particular story, the entire team is responsible for the completion of any work accepted into the Sprint.

Daily stand-ups are a good time for people who've completed their work to coordinate with others who need more resources. Likewise, a well-managed Sprint Backlog or kanban board will show team members where they can pitch in when they have excess slack time.

Also, stories that have slipped beyond the reasonable bounds of their estimates should be addressed in the daily stand-up. The team can then decide whether swarming over the story will be beneficial, or whether this represents a scope, scheduling, or resource issue that needs to be brought to the attention of the Product Owner for decision-making.


Give the team a pat on the back and some recognition for achieving their forecast. This is a great position to be in.

Next chat with the PO and then pull in some more stories into the sprint the team can try get done or even make a head start on. The key here is not to be idle and the team must keep busy.

  • Recognition is important, thanks. Commented May 20, 2022 at 6:15

As your Stories are identified with the MoSCoW (Must Have, Should Have, Could Have, Won't) If you finish early you can take from the backlog but without affecting the sprint goal, also if you didn't finish the new stories it shouldn't be a problem so I suggest that you choose from the should have and could have stories, by this way you add some feature to your increment without affecting your sprint goal, and use the team time in good productive way.

  • Hi Amir Serry, welcome to PM. Where are you reading OP is using the MoSCoW method? Commented Dec 8, 2019 at 10:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.