AGILE SPILLOVER

What Is Agile Spillover?

Spillover is when planned work (a product backlog item or story) is left unfinished at the end of the sprint or iteration and carries over to a subsequent sprint.

Spillover in agile tends to occur for one of three reasons:

• Ambitious sprint goal, or
• Too much unplanned work, or
• Underestimating the effort required to complete the work.

Occasional unfinished work is not a bad thing. In fact, it’s normal and desirable to occasionally aim a little high in a sprint and come up short.

Too many spillovers, however, can reduce predictability, diminish creativity, harm morale, and threaten project timelines.

Commitments Are Not Guarantees

A sprint goal is a commitment, not a guarantee. A commitment is a promise to try to achieve a goal. If forced to make a guarantee, a team will commit to less so that the guarantee is safe.

Sometimes we do need to make guarantees, such as when a client or customer needs some capability or a fixed scope by a certain date. In these cases, to ensure they meet that guarantee, a project team would likely cut back on other work and set a less ambitious sprint goal.

In general, though, we don’t want to force a team into a guarantee. Instead, we want them to commit to something reasonable, knowing we’ understanding if they miss it.

 

When Does Story Spillover Become a Problem?

Missing occasionally is not a problem. Habitual spillover is different.

Habitual spillover happens when agile teams almost always commit to more than they can complete in their sprints. They rarely complete what they think they will and end most sprints with incomplete user stories.

With habitual spillover, the end of the sprint becomes an arbitrary date, and unfinished stories are just carried over into the next sprint as if it’s no big deal.

Habitually rolling over unfinished stories to the next iteration is a big deal for two main reasons: it decreases predictability and negatively affects morale.

 

Side Effect #1: Lack of Predictability

The main problem with habitual spillover is a lack of predictability and dependability.

Every organization benefits from some level of predictability. Predictability shouldn’t be the primary goal, but it should be a goal. When your team is predictable, stakeholders will trust you and your work. There will be less second-guessing and micromanaging, so this trust benefits everyone. But don’t worry: you don’t have to be perfect to be predictable.

It’s the same in sports. A batter in cricket tries to score a hundred everytime he/she walks into bat. But a batter who scores above 50 most of the time is considered a high performer. That player can be depended on in big matches.

Similarly, a bowler strives to get 5 wickets in an innings everytime. However, they are considered very good bowlers, if they manage a 5-wicket haul (fifer) in 1 out of 10 matches and atleast take a couple of wickets in the other matches.

Like those sports players, agile teams are expected to try to deliver everything they think they can, every time. But if they achieve their goal 60–80% of the time, they are predictable teams.

 

Side Effect #2: Decrease in Morale

A second, related reason teams need to finish what they start most of the time has to do with the power of small wins.

Many studies have found that tangible, visible progress is a key factor in people’s enjoyment of work and level of creativity.

It’s almost impossible to get this tangible, visible sense of progress on “mostly done” but unfinished work. One reason is that until a backlog item is fully done, you can’t really gauge the amount of work remaining. This is known as the 90% syndrome. Software projects tend to be 90% done for 90% of their schedule.

When progress stalls, people lose their sense of accomplishment.

 

Why Does Overcommitment Become a Habit?

So why do some teams routinely try to deliver more value than they can reasonably expect to deliver?

The most common source of this bad habit is pressure. That pressure can originate from one of two places: external or internal.

External pressure can come from leadership, various stakeholders, or from any outside source. An executive or stakeholder can exert pressure by establishing unrealistic expectations in terms of budget or scope.

Sometimes this leadership pressure is well-intentioned. A leader gets excited about the opportunities presented by a product and wants more or they want to produce value faster because of the good it will do the company and/or the product’s users.

Other times, though, the pressure comes from misguided leaders who think pressure is an appropriate way to motivate others.

The second reason overcommitment happens is internal: pressure from themselves. Some teams allow their optimism and high expectations of themselves to create pressure to do more than is reasonable.

Whether pressure to overcommit comes from outside or inside, it’s neither a healthy environment for team members nor a good situation for the organization.

 

Three Ways to Stop Habitual Spillover

Remember, we want to stop habitual spillover, not all spillover. Sometimes teams miss their goals when they aim high and fall a little short. Don’t try to fix that kind of effort—celebrate it!

Other times teams miss because they just hit a run of bad luck for a handful of sprints. Again, no need to intervene there.

But when unfinished work spills over from sprint to sprint, here are three things you can do to help.

1.      Make Unfinished Sprint Work Visible

One thing you can do right away to help stop habitual user story rollover is to ensure everyone notices that unfinished work exists.

When this sprint ends, note the unfinished stories left in the sprint backlog versus how many were 100% done. Even better: look back at the prior sprints and count those spillover stories too.

Bring this information to the sprint retrospective and ask the team members why they think unfinished work has become a pattern for them. Walk them through exercises designed to uncover the root cause of a problem, such as 5 Whys. Then invite them to discuss options and identify one thing they could try next sprint to alleviate that root cause.

Don’t forget to hold them accountable to trying that idea (whatever it is) during sprint planning and as the sprint progresses.

 

2.      Curb Their Enthusiasm

Most often, incomplete work or unfinished stories are caused by an overabundance of optimism. People plan each sprint to be a best-case scenario and pull more work from the product backlog than they can achieve based on team capacity.

If that sounds familiar, in your next sprint planning meeting try asking questions like these:

• What could go wrong that could cause us to miss our goal (unplanned work, user story bigger than expected, unforeseen scenarios such as critical bugs, integration issues, and so on)?
• What has to go right to achieve this goal?

These questions can help uncover any risky assumptions about a story or about how easy the planned work will be. Think of it as a pre-mortem for the sprint.

 

3.      Drastically Under-commit

If increased visibility and pointed questions don’t result in more realistic commitments, a Scrum Master might have to resort to drastically reducing what the team brings into the sprint backlog.

At the next sprint planning meeting, encourage your team to truly under-commit in relation to their team capacity.

I’m not talking about cutting the sprint goal by some small amount, like 10–20%. I’m saying to limit team members to committing to only 50% of what they believe they can complete. (They might have to split user stories to do this)

The team may push back on this. They are used to filling up their sprint and will be optimistic that they can get more done than the items they’ve chosen. Scrum Masters should hold firm, reminding them that if they run out of work to do, they can always bring more in. (Scrum Masters will likely need to have a talk with the product owner prior to sprint planning so they too can be prepared to hear that the team is bringing only a few items into the sprint)

The goal in under-committing is to let everyone on the team (including the product owner) feel what it’s like to add a story rather than always needing to drop incomplete stories or carry spillover stories to a new sprint.  After they do, they’ll likely want to feel it again.

Once the team has felt the joy of no sprint spillover, Scrum Masters should encourage them to plan a bit more into the next few iterations until they get close to having to roll over incomplete stories again. Incorporate the enthusiasm-curbing questions as needed to prevent over-committing.

Habitual Spillover Can Be a Hard Habit to Break

Agile teams need to perform their best while also allowing the organization to create reliable plans. To do that, you want a team that knows its capacity and at the same time isn’t afraid to try hard things. You also need a product owner and stakeholders who understand that an ambitious team will not accomplish its goal every iteration and that understand the difference between a commitment and a guarantee.

Old habits die hard. Sometimes you have to take drastic action to realize lasting results.

- Coach Ram