Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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)?
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.
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:
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.
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.
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.
