Skip to main content

Why We Need to Stop Talking About “Carryover”

February 26, 2022

Does your Scrum Team have “carryover” from one Sprint to the next? Are you concerned about how to “account for carryover” when you calculate your team’s velocity? 

“Carryover” is not a thing in Scrum, and I think we need to stop using that terminology. Because by giving it a special name, it gets normalized. Plus the term itself is misleading. In this post, I will talk about “carryover” really means and how to handle it.

In my Professional Scrum classes, the term “carryover” is often brought up by students. And I always clarify for everyone what is actually being discussed.

“Carryover” simply means you have partially done Product Backlog items (PBIs) at the end of a Sprint. And I think it’s important to be very clear and direct about the situation, rather than giving it a name. Because everyone needs transparency to what’s actually happening, so we can effectively inspect and adapt. And since Done is the entire point of Scrum, it’s even more important to have clarity.

Now let’s consider the impacts of this situation. The best case scenario is that the team still has a useful valuable Increment, meaning they have removed this partially done work from the integrated Increment so that the Increment still meets the Definition of Done. The worst case scenario is that the Increment doesn’t meet the Definition of Done, and there is no useful value and zero benefits of business agility.

Either way, if you have started PBIs and not finished them by the end of the Sprint, you have waste in your process. Why is partially done work waste? Well, it means you’ve spent time on something without being able to get any value from it. That time could have been spent on something else that allows you to get a return on the investment now. It is also waste because you may end up not continuing forward with that PBI in the next Sprint because something else becomes higher ordered in the Product Backlog.

Yep, that’s right folks. You do not automatically carry forward partially done work into the next Sprint. The term “carryover” creates this misunderstanding. So that’s why we need to stop using the terminology of “carryover” because it continues to allow misunderstandings of Scrum and anti-patterns to persist. And it also distracts us from having better conversations.

In my next article, I will shed light on the 4 common misunderstandings and the better conversations we can have with our Scrum Teams.


What did you think about this post?