Scrum Strategies: What Should Be Done With Spilled Stories?
Source: Freepik
Some scrum masters see spillover as a mortal sin that needs to be avoided at all costs. Others see it as an inevitable part of any agile sprint cycle.
These polar opinions will obviously dictate how each side treats these spilled stories and how they structure their projects in general.
Is one opinion better than the other? That’s not for us to say. You may read this today and gravitate to one side or the other.
However, we want to provide an overview of the leading schools of thought on agile spillover, including the pros and cons of both. And we will let you know what one side would say about the other to defend their own philosophy.
Defining Our Terms: Acceptance Criteria vs Definition of Done
Before we get into the minutia of strategies, let’s be 100% clear on what we’re discussing.
The generally accepted definition of spilled stories (also known as spillover) in an agile cycle is stories that were committed to as a part of the sprint backlog, but not completed. However, how are we defining incomplete?
Are they incomplete relative to our Acceptance Criteria (AC) or our Definition of Done (DoD)? Because there is an important distinction there:
Definition of Done: The list of criteria that every Product Backlog item needs to meet before you move on to something else.
This is defined before the sprint begins and may include criteria such as quality, security, documentation, compliance, peer review, and many others.
Acceptance Criteria: The list of criteria that a given Product Backlog item must meet to ensure it meets the would-be users or customers’ needs.
For example, “A user must be able to log in to their account using their Facebook or Microsoft Teams profile.”
It’s important to know that, when we’re talking about spilled stories, these stories are incomplete relative to the DoD.
Now that we’ve defined our terms, let’s look at how leading teams are handling spilled stories.
Spilled Strategy 1: Avoid Them at All Costs
A lot of organizations will take a hard stance against spilled stories. They won’t move on until all backlog items are done, which could lead to the development team working overtime or the sprint timeline being extended or delayed.
The Argument in Favor:
This can foster a high-level commitment to meeting deadlines and deliverables to the product owner (PO) or client, while also protecting the team’s predictability.
The Argument Against:
Those who criticize this approach often say that this actually goes against the core ideology of a scrum and you’re actually treating the project like a short waterfall.
Many would also argue that this creates an environment that focuses on output instead of outcomes. They would add that a hyper-focus on predictability can come at the expense of agility and transparency.
Spilled Strategy 2: Move Them Back to the Sprint Backlog
If scrum stories are not completed, they could be simply moved back into the sprint backlog, where they will be reassessed and reprioritized by the product owner or client for the next sprint.
From there, one of three things would happen:
The product owner would ask the development team to keep working on the spilled stories in the following sprint.
The product owner may decide these stories are less of a priority than previously thought, then deprioritize them.
The product owner may discard the spilled story completely.
The Argument in Favor:
Scrum masters that subscribe to this mentality typically feel this method more closely mirrors classic scrum values.
They would also tell you that obsessing over closing out all stories is a result of common anti-patterns that place more focus on hitting metrics than adding value. Some would say, “It’s better to have spillover than broken features.”
The Argument Against:
Those who insist on closing out all stories in the backlog would argue that there needs to be a commitment to quality and achieving all goals on time. In fact, most teams that adopt an agile approach do so with the expectation and goal of hitting 90% of their deadlines.
They would also tell you that spilled stories are the enemy of predictability and make planning the next scrum cycle very difficult.
If we put stories back in the sprint backlog, should we re-estimate them?
If we’re going to put semi-completed items back in the sprint backlog, how do we treat the work already done?
You’ve estimated five points for a given story, but you’ve only completed 2 points in the previous sprint. When planning your next sprint would you:
Assign it five points again
Re-estimated based on the work already completed
Once again, there are differing opinions on this. Some would say that you should always re-estimate the story to reflect the actual work to be done. That way, you’re not wasting time.
On the other hand, some would recommend simply sticking with the 5-point estimate for the sake of simplicity. They would add that this approach ensures that you’re always focused on quality and not just burning tasks.
There is no right or wrong answer. There are only different ideologies and values.
The Most Common Causes of Spilled Stories (and One Secret Cause)
No matter how scrum masters feel about what you should do with spilled stories, they would all prefer to avoid them whenever possible.
Some of the most common causes of spilled stories include:
Unforeseen blockers like turnover on the team, sick days, or system downtime
A lack of visibility into dependencies
Overestimating what you could complete in one iteration
Underestimating the work involved in one or more story
The DoD wasn’t accurate
A priority shift from the PO or client
An overall lack of communication between the PO and the team of developers
A lack of collaboration between the developers on the team
Scope creep on one or more story
Developers having access issues with the required code repositories
Something becomes blocked due to another unmet dependency
Any of these common challenges can lead to spilled stories and drive scrum masters crazy. However, there is one secret problem that can exacerbate all of those problems: Ineffective Program Increment (PI) planning.
Why does this happen? In a lot of cases, the PI planning process is rushed because of aggressive deadlines.
At the other end of the spectrum, agile team members often complain of long and unstimulating planning meetings, which leads to them disengaging or “tuning out.” At the same time, scrum masters often struggle to coordinate teams working remotely in different time zones.
