How to improve predictability of product delivery by managing spilled stories?

Achieving predictable outcomes with product delivery is critical for any business today. Business leaders and customers do not want to be surprised with milestones not being met.
While the business leaders look to product and engineering teams for a more predictable delivery of their initiatives, managing spilled stories is a key component and early indicator for product and engineering leaders.
Spilled stories are backlog items that did not meet the criteria defined in the Definition of Done (DoD) for the scrum team. In order to meet these requirements, DevOps teams and lean practitioners have to constantly improve themselves.

Problems with Spilled Stories

Spilled Stories are usually identified during the Sprint Demo and Retrospective meetings; can give trouble to the scrum team members and product owner.

Reasons for Spilled Stories

1. Improperly defined Definition of Done – If the Definition of Done is not defined properly, and the team finds out that later in the sprint, they may end up in a dilemma to mark the stories as ‘done’.
2. Having a Proxy Product Owner – Having a proxy product owner creates more problems rather than solving any. First and foremost is 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 the 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. Having a dedicated Product Owner will help the team to gain a better understanding of the requirements and thereby reduce unnecessary delays. More the team members know a Product Owner, they understand what and how of the product.
3. Overestimation of work for the sprint – The team becomes over-ambitious and commits too much more than they can deliver.
4. Unforeseen circumstances – There may be a situation where a team member becomes unavailable due to sickness, other work commitments, or personal commitments.
5. Change in priorities – Product Owner may decide to change the priority of stories mid-sprint or stories may even become a higher priority with technical limitations. As a result, stories may not be completed and may get spilled over to subsequent sprints.
6. Dependency issues – If the required dependencies are addressed, it could be also one of the reasons for spilled stories. Some examples are:
   • Unavailability of required infrastructure
   • Unavailability of a component/ module/ backend database items to complete a user story. 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.
   • Access issues – team members not being able to use the required code repositories

How to deal with Spilled Stories

It is important to devise a strategy on how to manage the uncompleted work. Following are some of the recommended practices: 

• Review the process followed by the team during the sprint retrospective session. As the team discusses and identifies the root cause for what did not go well during the sprint, the reasons for spilled stories can be identified and actions can be planned to mitigate it. It could be that the cause for most delays may be common and the team has to understand the factors related to delivery delays to quickly move on to discuss other aspects important for project success. The following scenario provides an example of why is it necessary split a big user story to avoid spillovers:
• Let’s say a team picks up a 5-point story in Sprint 1. At the end of the sprint, the team estimates that they have completed 2 out of the 5 points. However, at the end of the sprint, the story (and all 5 of its points) will be moved to Sprint 2. Assuming this is the only story in Sprint 1, velocity of the team according to JIRA will be:

• • Sprint 1: 0 points
  • Sprint 2: 5 points
• This approach has following problems:
  • Team velocity is not accurate because the team completed 2 points in one sprint and 3 points in subsequent sprint. But JIRA considers it 0 and 5 respectively and results in inaccurate reporting at the end of the sprint.
  • It’s not clear how many points are actually in Sprint 2 at the start of the sprint, forcing capacity calculation to occur manually. It appears to be 5 points but in reality, it is only 3 points.
• The way to fix this is as follows:

• The team has to observe if they are taking too many points into a sprint and end up delivering less. If yes, the team should not commit too much, and has to reduce the points that are being taken in or has to lengthen the sprint duration to allow more to be done. This decision can be taken by analyzing the situation in retrospective meetings.
• If the team finds out that stories don’t fit into one sprint, they have to split them into more manageable chunks before starting the sprint and take only those that can be delivered.
• Team has to get better at estimating and has to consider all the dependencies that are to be addressed for them to deliver.

• Team has to discuss the required actions to be taken on the user stories that got spilled over. The Product Owner has to decide whether the stories are still on high priority or not.
  • If yes, then the story can be taken up in the next sprint as it was already decomposed to the most granular level during grooming and. If the story was done partially it is important for the team to discuss the amount of work remaining to complete it. This analysis may result in the creation of a new user story (for the remaining work) with new acceptance criteria, a new DoD, and a new estimation.
  • If the story is not on priority, then move the story to the bottom of the product/ release backlog. The story has to be prioritized during backlog grooming, re-estimated and has to be taken up in future sprints.
• The Scrum Master has to understand the availability of the team members for the entire duration of the sprint and has to plan the amount of work that can be taken up accordingly. Capacity based sprint planning is one of the approaches that can be adopted by a scrum team to avoid spilled stories. Including some buffer in the capacity plan for unplanned work is always helpful.
• Refine the Product Backlog before Sprint Planning – It is  better to have product backlog refinement sessions in advance to reduce ambiguity. Scrum Master has to coach the team on the importance of having 1–2 sprint’s work refined in advance to avoid spilled stories.
• A scrum team has to dedicate more time for planning by defining a proper goal for the sprint and ensuring that all user stories are aligned with the sprint goal. The scrum team has to set aside some buffer time for unplanned work which will give the team some breathing space just in case a story runs for more than planned.

Kaiburr helps every product engineering team to measure their performance near real-time using industry-standard KPIs like those shown below –