11 Tips on How to Avoid or Stop Story Spillover in Scrum

Do you struggle to complete planned stories within the timebox in a scrum, or does your team struggle? Why do we have spillover? What are the reasons behind it, and how to avoid and stop it? Is it possible to complete all stories in every sprint? If not, what is acceptable? We use Scrum to solve complex problems that mean uncertainty and complexity are always going to be there.

In such cases, we cannot be accurate, and sometimes it can be more than what we plan or less than that. I usually consider a 20% variation in planning but must have the sprint goal to enable this flexibility. I will talk about the sprint goal in my next article so, let’s focus on reasons and solutions for story spillover.

Recommendations on how to reduce or avoid spillovers

• 1

  Team Forecasting More Than Capacity — Not considering team capacity and velocity during sprint planning leads to such issues. The Scrum master should help the team understand the importance of capacity and velocity during forecasting, so the team stops overcommitted.

• 2No Room For Unplanned Work — It is expected in a complex domain where the team looks for continuous feedback. It can be in the form of change requests or production issues. It is advisable not to plan for your full capacity to accommodate those feedback during the sprint. Keep some time reserve for experiments and unplanned work based on historical data. The team can always pull more work within the sprint if the team has extra time.
• 3No Teamwork- Every member is picking up the story based on individual skills and ability. It also leads to poor daily Scrum because nobody pays attention to other member’s work. Look for the possibility of having more than one team member working on the same story. If needed, better keep bigger size stories that add value rather than keeping stories small with no value.
• 4

  Missing Definition of Done - Either team doesn’t have a definition of done or have it very minimal, which doesn’t enable transparency in increment produced by the team, so changes keep coming throughout the sprint. Have a definition of done that helps in creating potentially releasable product increment with higher quality will help.

• 5

  Undone Work - The team does not produce potentially releasable product increment and keeps accumulating incomplete work such as UAT, performance testing and security testing, etc. Later on, these works start appearing in sprint backlog as and when those works begin. Minimize or eliminate those undone work by improving your definition of done and doing all work within the sprint.

• 6

  Not Refining Product Backlog Before Sprint Planning - Scrum says to keep your product backlog ready for the sprint planning, and not having it will lead to an ambiguous plan. Better to have product backlog refinement sessions in advance to reduce ambiguity. I coach the team on the importance of having 1–2 sprint’s work refined in advance to avoid this issue.

• 7

  Not Updating Sprint Backlog Regularly - Whatever the reason, I have seen many teams that don’t update the task board when the task’s status changes. The sprint backlog doesn’t reflect correct insights, so they don’t get needed support from anyone promptly. Having a team agreement encourages such practices to enable transparency in the sprint backlog to reflect an accurate picture.

• 8Inter-Team Dependencies - While working in a multi-team Scrum setup, it is always challenging to deal with dependencies. Where teams spend a lot of time in coordination and meetings, having a feature team reduces such dependencies. Also, avoid component teams like service teams, UI teams and backend teams, etc. Each team should be capable of delivering a customer-centric feature.
• 9Missing Inspect and Adapt During Daily Scrum - Have you been in the daily Scrum, which sounds more like a status report? Scrum Masters collects status and compiles a piece of information for stakeholders? If yes, you are missing the real purpose of the daily Scrum. Use daily Scrum to inspect your sprint goal, work done so far to meet the sprint goal, and decide the most important work that the team can do today.
• 10Having a Proxy Product Owner - Having a proxy product owner creates more problems than solve any. First and foremost, delayed decision making. Proxy collects queries from the team and clarifies with the product owner, comes back, and explains to the team. If the team comes up with more queries, then proxy again goes to the product owner. The team loses a lot of time and ends up waiting for information or pulling more stories to work on it. Not having a proxy will help in improving the relationship between developers and the product owner. More they know each other, better understand what and how of the product.
• 11No Empiricism- Finally, the team is not learning from the previous sprint’s outcome. Retrospectives are more like a blame game or dull, so nobody is challenging the present issues. Learn and apply the empirical approach in your Scrum to improve your product delivery. That’s all for today. Please write your feedback in the comment section about these tips on stopping and avoiding story spillover.