If you’ve been using Scrum for more than a few Sprints it’s inevitable that you have had incomplete work at the end of a Sprint. Even teams very experienced with Scrum will encounter this. Yet I continue to meet teams who ask about how the incomplete work should be better handled or even eliminated. These desires show some misunderstanding that I’d like to clear up in this article.
What is carryover?
Incomplete work at the end of a Sprint is very commonly called “carryover”. Likely because that’s exactly what most teams do, they automatically “carry over” the work directly into the next Sprint.
This makes the assumption that the unfinished work still has high value when completed. Which may or may not be the case. As such, a conversation should be had whether or not to continue that work.
But I want to explore some other aspects of carryover work.
Misconception #1:
The vast majority of the teams I’ve encountered use a combination of estimation and average to assist in planning Sprints. Typically in the form of Story Points and Velocity (the average number of Story Points completed per Sprint).
During Sprint Planning the team will review their velocity and perhaps adjust a bit based on expected time variation from normal for the upcoming Sprint. They will select an appropriate number of backlog items whose combined estimates equals their velocity, or very close to it. Then the Sprint proceeds as normal.
At the end of the Sprint the team will rarely finish, at the very end of the Sprint, exactly what was planned during Sprint Planning. More often they will complete the planned work early or there will be incomplete work at the end of the Sprint.
When there is incomplete work several things may happen. The team may feel they failed to deliver their “commitment” (more on that in a bit). The Scrum Master, Product Owner or management may shame or penalize the team for not completing everything (again, see below).
The misconception, or misunderstanding, is one of math, not effort or commitment.
People are forgetting that, when using an average, about half the time more than the average is accomplished and similarly about half the time less is accomplished when compared to the average.
If teams are using an average to plan they will, on average, complete less than that amount about half the time. That’s how averages work.
Yet often the outcome of this misunderstanding is considerable efforts to “get better at estimating” rather than simply understanding what to expect – when using an average about half the time the team will complete less than that amount.
Enough about that one.
Misconception #2:
Another very common misconception that likely most teams still hold is that during Sprint Planning the team “commits” to completing all of the selected backlog items. There are even “metrics” used to determine if the team completes their “commitment”. One such metric is what I call the “Say – Do” percentage. The calculation is the number of story points completed divided by the number of story points “committed”.
For example, during Sprint Planning the team selects 20 Story Points worth of stories. At the end of the Sprint the team determines they completed 15 Story Points, or 75% (15/20) of what was “committed”. Anything less than 90-100% is often deemed a failure.
What these teams are failing to understand is that considering the exact stories selected during Sprint Planning as a “commitment” is incorrect. That has never been the intent. In fact, the Scrum Guide made it perfectly clear in 2020 by stating:
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.
Scrum Guide 2020
The team “commits” to delivering the Sprint Goal, not the exact stories as selected during Sprint Planning. Those are allowed to flex, or adapt, as needed to deliver the Sprint Goal. Items may be added, deleted or even updated as long as they do not jeopardize the Sprint Goal.
Using “metrics” such as the Say – Do measure mentioned above can limit the team’s agility by encouraging them to “stick to the plan” rather than pivoting when they determine they should. Otherwise they risk failing metrics with potentially negative consequences.
In fact, the Sprint Goal may be delivered without even completing all of the Sprint backlog. It may be completed sooner at which point some work items can be removed.
So, the attention on the exact items selected during Sprint Planning “completing” is the incorrect focus and the wrong validation of the Sprint commitment. The commitment is to the Sprint Goal.
So now that you are aware carryover can be expected in Scrum teams that plan using an average, and that the focus should be on the Sprint Goal rather than the individual exact work items selected in Sprint Planning, you might have a question.
How much carryover is “OK”?
Two assumptions:
- The team is fully cross-functional. They contain all the necessary skills within the team to complete the work and are working as a team. The team views all work as “their” work rather than “my work vs your work”.
- Work items are mostly or entirely vertical slices rather than component stories. Examples of component stories are one for BE work and one for FE work for the same piece of functionality that will be later integrated.
In these situations teams will swarm to unfinished work rather than starting new work near the end of the Sprint. The focus will be completing what has already been started. In this scenario the team would likely carryover one work item, very occasionally two. If there are more discuss in the next retrospective.
If the team is consistently rolling over more than one work item then examine the assumptions above. The group may not be working as a team. They may be working individually and perhaps even being measured individually (how many work items or points completed per sprint per person).
Or the work items may be component based and the team is unable to swarm individual items as effectively as they could with vertical slices.
Wrapping Up
Most teams that I encounter are not dealing with carryover with the above information. Management and teams are targeting “zero carryover” in Scrum teams. This is not a realistic target and having that as the goal will likely lead to teams “sandbagging” Sprint Planning to take in less than they might otherwise.
So, in effect, value delivery will decrease in order to stay under the radar. An unintended consequence for sure but it stems from a lack of understanding how averages work and an unrealistic expectation of how Scrum works within teams.
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
