The sprint backlog is a subset of the product backlog that the Scrum Team commits for an iteration, after careful consideration and deliberation, during sprint planning. But spillover (the inability to meet the "Done" criteria for all stories) continues to be a reality. With a forming team, the probability of spillover is even higher. It is absolutely critical to draw patterns from the spillover to identify the root causes and apply the learnings to subsequent sprints to avoid its reoccurrence.
Patterns that lead to spillover
You might observe the following patterns that typically lead to spillover of the sprint backlog.
Incomplete user stories
An overly committed sprint backlog that may have been planned with insufficient buffers is more likely to slip. User stories that are not thoroughly scoped, dependencies that are not factored in, stories written with only development activities in mind, or stories written without considering the associated user value are some of the other common reasons for spillover. The team that picks up such a backlog tends to spend unproductive time on rescoping stories and sorting dependencies.
Lack of communication and collaboration
Improper communication or not being actively engaged in daily stand-ups also leads to spillover. Often, development and testing engineers do not communicate clearly, leading to resources assuming expectations and commitments — for example, testing may assume that development will signal when to start.
To expedite and remove redundancies, the developers, on their own, often provide builds to the tester without unit testing, which creates a scenario in which the testing effort is wasted on basic code issues. Multiple "private" build exchanges between the developer and tester constitute another reason that increases the turnaround time, and eventually the stories spill. This is typical of a group of individuals who work on a team but without the spirit of collaboration.
Inefficient Definition of Done
To make the Definition of Done (DoD) exhaustive, the organization may set up a complicated set of Done criteria. To meet this DoD, the team must identify too many story tasks, and the usual sprint duration might fall short of accommodating all of them.
Some other inefficiencies include traditional testing approaches, planning automation toward the end of sprint, and generating builds with outdated setup (which is time-consuming).
Parallel versus sequential: The right mix
Rather than estimating effort required to work on prioritized stories sequentially, Scrum Teams start on all stories committed in parallel. For example, an eight-member team starts on the sprint backlog of four stories simultaneously, with two engineers per story. If any unanticipated event occurs whereby the top priority story requires more man hours, without reshuffling the resources, the team can’t complete the top stories.
Spillover: Opportunity for improvement
In some cases, user stories will spill over from one sprint to another. Here a several tips that can mitigate spillover.
- Committing to the next sprint should be done carefully, considering how much effort will be spent to bridge the gap. The product owner and technical leaders must thoroughly analyze spilled-over stories to identify contributing factors and help the Scrum Team address them.
- Writing user stories with well-defined scope and acceptance criteria is the best way to avoid spillover; if the user story complexity is medium but the line of code required is huge, having the correct acceptance criteria will define the right scope of work. The product owner and subject matter experts should invest sufficient time in breaking down epics into user stories.
- Avoiding redundant testing and identifying the right amount of automation can be crucial to efficiency and help to reduce future occurrence of spillover.
- Meeting the DoD set for any organization doesn’t mean that each user story needs to meet the DoD. It’s up to the Scrum Team to determine how they will leverage the Done criteria without creating any technical debt or compromising on quality.
- Developing focused communication and collaboration strategies — like one-on-one discussions or team discussion platforms — may avoid slippage. Sometimes developers just linger around a story for the entire sprint without seeking help from fellow team members.
- Religiously syncing up among the Scrum Team members and having a sense of urgency and commitment toward their own decision will be helpful.
- Periodically checking the Scrum Team task board also helps to identify possible spillovers. If a certain task sits on the same status, there might be some obstacle hiding behind it.
It’s OK to have spillover when there is an unavoidable situation that cannot be anticipated, even after proper planning and discussion. But frequent reoccurrence of spillovers is a pattern for concern. The ScrumMaster, along with concerned stakeholders, plays a significant role to make the necessary adjustments. It is important to have meaningful retrospectives to learn and identify action items. Continuous implementation of those action items and periodic reviews will be helpful to avoid any future spillovers.