The Truth About Carryover

04:56 reading time


When you are new to Scrum, it’s easy to focus on the concept of finishing everything you have committed to within an iteration. Because when the process instructs that you write user stories of manageable size and deliver small increments of functionality, it’s unsatisfying when the work is not done by the Sprint Review or the next Planning session, right? That is how we define carryover – work that was not done in the sprint but is still valuable, so the story needs to be carried into the next sprint for completion.

Let’s be honest. It’s not just people who are new to Scrum who feel this way. It’s veterans, too. Carryover tends to create uncertainty because it doesn’t seem to fit cleanly into the Scrum framework. But what we are learning is that carryover is as much a part of Scrum as the Daily Stand (if it weren’t, would it have ever received a name?). There are a number of reasons that carryover can happen, these are just a few we witness at Leapfrog:

  1. We under-estimated the story, and the work involved is much more than we thought. We thought the story was a configuration change, but it was actually hardcoded in 17 places, requiring a lot of updates and extensive User Acceptance Testing before deployment.
  2. Interrupts. Every team deals with this to some extent. Something comes along that needs more attention than the time we set aside for interrupts. It could be unexpected host failures, a Production-facing bug, or HR trainings that took longer than we thought.
  3. The engineers working on the story are not familiar with the code base. Maybe it’s a relatively simple story, but you have never worked on the product before and need to spend three days understanding how everything fits together.
  4. We committed to two other stories that involve the same code base because they were the top priorities, but none of our code is playing well together. (There are many ways to avoid stepping on someone’s work that I won’t go into. This point is more about needing to refactor your work to make sure all of the pieces fit together before anyone’s code is deployed).
  5. The story was blocked waiting on someone outside the team to help us finish it. Maybe your Account Manager couldn’t UAT in time before the end of the sprint.
  6. We finished everything originally committed to in the iteration, so we pulled in some additional stories that won’t get finished. This is especially true when the highest priorities in the backlog are large stories that need to come next.

All of these are legitimate reasons for work not being completed in a sprint. What I have come to realize is that the structure of an iteration is, in many ways, just a guideline that enables a team to come up with ways to deliver smaller increments of functionality that can be iterated on until it’s just right. The timeboxed sprint encourages us to think about delivering less complex functionality and more quality, and it should be functionality that we can continue to improve upon as the needs of the business evolve.

A couple of things could happen if a team doesn’t accept carryover as an option. Teams might reduce the quality of their work to finish something in time, neglect to reprioritize the work based on the needs of the organization, or in really unfortunate circumstances, someone might feel singled out about why the story couldn’t be completed. All of these will add negative feelings to the team and, over time, reduce the health of the team.

Leapfrog teams have chosen the path of accepting carryover as part of the way we work. So, if you also choose to accept carryover, I have a couple of suggestions to make it work.

  1. Talk about it. You committed to stories A, B, and C as a team, so every member of the team should understand which story and why it is being carried over. Just about all of the Scrum rituals are great opportunities to have transparent conversations.
  2. Remind each other that it’s okay not to finish a story by the end of the sprint. We care about quality and not an artificial deadline. Reassure each other that carrying over a story is not failure but perhaps a learning opportunity for future work.
  3. Understand what needs to happen to complete the stories. Do we understand the acceptance criteria? Does the engineer working on the story need someone to explain the code? Does the Scrum Master need to work with other teams to unblock the story? Is it still the top priority for the team to complete?
  4. Remain aware of how often carryover shows up for your team. It could be an indication that the team needs help with their estimation technique, that a bottleneck in the flow of work is slowing them down, or that there is a persistent lack of understanding about the requested work. Addressing these concerns may reduce carryover, but more importantly, it will aid the team in frequently delivering valuable software.

It’s easy to feel like carryover is taboo, but it is actually a normal part of the Scrum framework. However, a word of caution. If carrying stories into the next iteration becomes habitual because stories are consistently too large for a sprint or the team is frequently pulled off track for other issues, it may be time to reevaluate how well Scrum is implemented at your organization.


Bf66fc392a9ecbd714826d21955ac1e9

Hillary Truty
Scrum Master