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:
- 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.
- 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.
- 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.
- 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.