Sprint Carryovers Are Bad!

Your team reached the end of the Sprint. Things seem to have been going well. A lot of work has been completed and it feels like celebrations are in order until, clicking the “Complete Sprint” button you realize that oh oh, there are some stories that need to be rolled over into the next Sprint. Certainly, it’s understandable. Gently, you push that OK button and see those unfinished stories and tasks copied into the new Sprint. Then, you pause, think about it a minute and realize… Oh boy, that story has been carried over into the new Sprint for a 3rd time now. It’s not complicated, it’s not time consuming, and priority is relatively high. However, it still, despite all the planning, has not been done. 

Can’t be that bad, right? Well, let’s pull down the report and surely, the report makes the carry over obvious. Darn, now there is a mark on our good Sprint. During the Sprint Review meeting, holding your head high you focus on presenting a custom Sprint Review slide aiming to celebrate the wins and obviously hide the loses. Quietly hoping the only metric discussed is the team’s expected velocity, and that the rolled over story count question does not come up.

Why are we so afraid of Sprint carryovers? Well, the managers make this very clear – Sprint Carryovers are Bad! But really, are they?

Turns out that the Sprint carryovers are not at all bad. They are not good. But they are not bad either! They are not an evidence of poor performance, but merely an indication that a certain amount of work – planned or unplanned has not been completed this Sprint.

Now, what about a Story being rolled over several Sprints in a row? That’s not great either, but it’s also not bad. And similarly to any carryover, it’s merely a symptom. So, putting aside the typical manager who may decide to criticize the team for the carryover, how do we explain that carryovers are not bad?

Well, the first thing to do here, is to admit that Agile is a journey, not a destination. And anything discovered during this journey is an opportunity to learn and evolve the growth mindset – evaluating what has happened in order to come up with a much better alternative. 

So what is a Sprint carryover? What does it indicate? Well, any amount of uncompleted work means that scope of the effort for the Sprint was underestimated. Why? Good question, it depends… There could be many reasons. Some work items could be greatly underestimated, or there were too many unrelated interruptions preventing work from getting done, in-Sprint defects, support cases, or many other reasons. 

What carryover means is that ultimately, the team could benefit from reviewing how it scopes and sizes stories during kickoff, and what additional discovered work may have impacted planned Sprint commitments. And, if the item is carried over several Sprints in the row – then the team should assess how it reviews each Sprint’s commitments to ensure that scope wise, the amount of work for the Sprint matches with the Team’s Sprint capacity. 

Interestingly, better performing agile teams typically have carryovers. It is part of their usual experience, as they always aim to accomplish more. However, similarly to diabetic attempting to have a better control over the sugars and keeping the numbers closer to a perfect range increases the risks and chances of overrunning the limits. With tighter control, the frequency of Sprint carryovers will be much more frequent. And that’s OK. The current Sprint may see a carryover, but it’s the future Sprint that will reap the rewards, will experience an increase in velocity.

So, stop being so preoccupied with Carryovers. And please, please, please make sure not to make it a Vanity metric either. Last thing you want is to guide the team to limit the Carryovers. Sure, limiting Carryovers can be achieved, but it will be done by severely under committing and hence promoting too much rigor, less energy to strive to do more, and obviously poorer results. Lets say it together, Carryovers are not bad!

Distributed Teams in a Post-COVID World