In my last article, I explained why we need to stop talking about "carryover" and how it's not actually a thing in Scrum. "Carryover" is really just partially done work at the end of a Sprint. Now I will take you deeper and share the 4 common misunderstandings often associated with this concept, and how we can make the shift to creating better conversations about what really matters.
4 Common Misunderstandings of "Carryover"
#1 - Product Backlog Items (PBIs) that are planned in a Sprint and not finished are NOT automatically planned in the next Sprint.
Things may have changed in our environment that affect the order of the Product Backlog. The Product Owner is accountable for what is in the Product Backlog and the order of it. One of the benefits we get from the Sprint is having the ability to change direction every Sprint. If we just assume work that didn't get done moves into the next Sprint, we are missing the opportunity for the Product Owner to determine what is the next right thing to work on in order to maximize the value of the product.
Any PBIs that are not completed in the Sprint get put back in the Product Backlog, and they would be updated, re-estimated, and re-ordered to reflect what we know now. That helps ensure we have a transparent Product Backlog.
#2 - It is NOT okay to have partially done work in an Increment.
Partially done work is not part of an Increment because that would reduce transparency to progress and limit the ability to release value and get meaningful feedback. If there is partially done work towards the end of a Sprint, it needs to be removed from the Increment so that the Increment meets the Definition of Done.
Is this creating waste and potentially leading to re-work? Yep. Because that time could have been spent on creating something that would enable us to realize value now. And when we do come back to partially done work, we will have to get ourselves ramped back up on what it is and what work remains. It is also likely that the product has changed in ways that may require re-work or even throwing away the previous work.
We need to be open and honest about how partially done work is limiting our ability to frequently deliver valuable quality solutions.
#3 - Velocity does NOT matter.
Yep, I said it. I don't care what your velocity is, especially if you're trying to "get credit" for partially done work.
I am often asked how to "account for carryover" when calculating a team's velocity. Well, if your velocity reflects partially done work, it is meaningless anyways. And it could even lead to reducing transparency to progress and lowering quality. Remember that velocity (or any type of throughput measure) is simply an indicator of your team's past ability to turn PBIs into a useful, valuable Increment in a Sprint. It is to be used by the Scrum Team to help them with forecasting. It's not a team performance indicator.
What matters is delivering valuable, quality solutions frequently. I also like to say this as: outcomes over outputs.
This leads right into the fourth misunderstanding.
#4 - The goal is NOT to be perfect planners.
Scrum Teams are not always going to get their Sprint Backlog "right." They may come up with a Sprint Goal that they cannot meet in a Sprint. The Developers may select more PBIs than they can get done in a Sprint. Because even at the time horizon of a Sprint, we have complexity and unpredictability. We do the best we can with what we know at the time.
And this is why the Sprint Backlog is frequently being updated to reflect new learnings as the Increment emerges.
The Solution: Shift Focus to Having Better Conversations About What Matters
When we use the term "carryover" to normalize having partially done work at the end of a Sprint, we are losing the opportunity to have conversations about what really matters.
Here are some prompts that can lead you towards better conversations. This is where we get to meaningful transparency and effective inspection and adaptation, so teams can navigate complexity and respond to change.
- How can we improve the way we work together during a Sprint to more consistently have a useful, valuable Increment that meets the Definition of Done? And how can we do that without waste from partially done work?
- Why are we finding out so late in the Sprint that we aren't going to get the in-progress PBIs to Done? How could we reduce the risk of this happening? How can we limit our work in progress?
- How effectively are we using the Sprint Goal and our Definition of Done during the Sprint to create focus and create a shared understanding of our progress?
- How effectively are we leveraging the Daily Scrum to understand our progress towards the Sprint Goal and collaboratively plan the most effective way to work together for the next 24 hours?
- What impediments exist that are slowing us down or reducing transparency to our progress during the Sprint? What conversations do we need to have in the organization to bring transparency to the impacts of these impediments?
- If there is a pattern of consistently planning more than we can get done in a Sprint? What factors do we think may be contributing to that? And what impact is this situation having on our team? Is there something different we want to try for Sprint Planning?
