Scrum Myth #3 The Spillover Is A Cardinal Sin In Scrum
Over and over again, I face a situation where a team is pressed for finishing all work items that are in the Sprint. Usually, they have no Sprint Goal, or there is a list of goals that reminds the list of stories in the Sprint. It basically means that no one knows why finishing these tasks matters at all. Or perhaps they just assume they all matter equally. All in all, the management only considers it a success if there’s no spillover.
Does it remind you of anything? Encouraging a feature factory perhaps?
Let’s see what can be a worse problem for the team and the company rather than a bunch of unfinished tasks.
After Myth #1 and leaving the PO out of the team, we had Myth #2 where we were obsessing about the estimates. Here we go with Myth #3, the spillover obsession.
We will go through the anti-patterns, then I will give you a more pragmatic approach to Sprints.
Let’s start with the anti-patterns, although I can’t think of many apart from the typical ones:
- The team must finish all the items in the Sprint
- Spillover is bad, don’t do spillover
Oh I know another one
- We haven’t finished the story but let’s just close it and create a new one for the next Sprint with the remaining work.
- Why not close all unfinished stories and create new ones for the new Sprint
And if we decide to let the stories spill over
- Shall we re-estimate all the unfinished stories for the new sprint
- Management asks for an explanation of why each of the stories hasn’t been finished
Do you see a pattern in the last two myths? Myth #2 and #3 have something in common: a misunderstanding, dogmatism, and focusing on making the metrics happy as opposed to delivering value. The obsession on a given practice or metric.
The focus on finishing all the Sprint Backlog leads to some dysfunctions:
- Teams plan just enough to make sure they finish all the work even if it means
a) there is slack time added for the team members
b) the team would leave out some important work (since nothing has a distinguished priority) just to prevent it from spilling over
- Planning becomes very conservative
- No clear objective to achieve in the Sprint, all items are equally important
- Sprint Review becomes not about the outcome but the output, we discuss each and every story
Everything aside, this gets boring! How do you want to motivate the team to run another Sprint?
Is spillover good or bad?
I’m not saying the spillover is good. Not even that it is bad. Let’s go beyond black or white. Spillover is a natural side-effect of running Sprints.
When you cook dinner is it only successful when you have just enough for the people at the table? Well in this case having not enough is not the best thing. But the leftovers are not the worst, it’s actually better to have them than not have enough food for the people. There are many options to deal with the leftovers.
Would you ever obsess over cooking just enough? Or would you rather obsess about fulfilling the goal — feeding people in a way they can actually enjoy both the food and the company?
Yves puts it nicely for us:
“Spillovers can happen, for some tasks, it can even be considered normal as they can be less time critical. The most important is to add more value and collect feedback from various stakeholders and customers. Too many spillovers could be a sign that the team is working on too many items and it would be good to commit to fewer items and set a less ambitious sprint goal. Spillovers also happen a lot when the Scrum Police defines how many story points have to be committed per sprint.”
And Wilem seconds that adding a point about the leftovers:
“There is no fixed scope. Better to have spillover than to have broken features. And as others have said already, it is the goal that matters, not the SBIs.
However, also don’t just automatically pull them into the next sprint. Sprint review may have proven them outdated or insignificant, or maybe priorities have changed. Let the new goal lead your next sprint, not the leftovers.”
What about the value?
It’s hard to know what to focus on if you are not given a direction. I asked on LinkedIn if spillover is really that bad. Here are some answers I agree with:
“The only measure of any importance on any Sprint is the value delivered.”
Value delivery over “successful Sprints”.
“Forget the PBIs.
Did you achieve the goal?
As soon as you do that, the sprint is successful.”
“I’d argue a sprint’s success is measured by the delight on the faces of the customers, not upon what items have been completed. That’s like measuring how great a meal tastes by the quantity of chips on the plate.”
What about team predictability?
I know what you’re thinking — what about the predictability? Isn’t that the goal of having high-performing teams?
“Predictions can change based on new circumstances. We need to be adaptable.”
Then we go back to the roadmap as a guarantee of the delivery.
Of course, we want to reach a certain level of predictability with the teams. It helps with the planning. I would just advise against putting it as the main goal of the teams. The goal and focus have to be on delivering value and understanding the customer's perspective. Not obsessing over deadlines. To give it a spin — What if we deliver early? Is that bad either, because we missed the deadline?
That’s all for today, I hope I managed to give you a different perspective on the spillover. Let me know what you think about it in the comments!