How Bad Are Sprint Carry-Overs

Do you look backward or forward when you start your Sprints? When I began working with Scrum, I used to put too much emphasis on carry-overs. They bugged me quite a lot, and I started sprinting, annoyed that we didn’t deliver our previous commitment. That was my flawed perception, which stressed the whole team at the beginning of almost every Sprint.

After working with many teams, I realized that carry-overs are everywhere. Dealing with them is part of the job, but how you do it may trap you into traditional project management. The following questions during the Sprint planning should alarm you:

• How much is missing to deliver the remaining items?
• How confident are you to deliver it, as we’re now carrying it over for a second Sprint?
• Should we close this item to reflect our velocity and create a follow-up ticket?

I don’t perceive any of these questions as helpful. On the contrary, I consider them antipatterns. Be careful with them because they won’t help you deliver value faster.

Why are carry-overs often such a problem for Scrum teams? How could you deal with them better? Stick with me, and I will try to get these questions answered with a simple example of a chatbot.

Some time ago, we realized customer satisfaction had sunk, and one of the main reasons was a poor customer service experience. Whenever customers had any problem, it’d take them days to hear back from us. We were understaffed, and this situation was not going to change any time soon. So we decided to implement a chatbot as a remedy for these problems. That’s where an ever-lasting carry-over journey started. Let me walk you through the three pitfalls we’ve fallen into.

1. Project Thinking vs. Product Thinking

Our first obstacle was how we approached delivery. We decomposed a chatbot implementation into different Sprints. And, of course, we underestimated the required effort to ship something valuable, which led to endless carry-overs from Sprint to Sprint. 

Why did that happen? Project thinking trapped us.

How you think is decisive in how you play the Scrum game. For a long time, crafting a perfect plan and delivering on time, within budget and within scope, were our primary definitions for success. It’s unbelievably hard to start thinking differently, but it’s necessary, unless we want to remain trapped forever.

To illustrate the differences between project and product thinking, let me refer to a recent post from Aakash Gupta. He summarizes in one image the critical differences between both approaches.

What’s the challenge we’re facing? Our minds are still focused on outputs. We spend most of our time in the solution space and assume the outcome will be a given. Well, I must tell you that if you don’t put significant energy into uncovering what drives desired outcomes, your solution will result in unpleasant surprises. I’m sure that’s not what you want.

Coming back to our chatbot example. We had a project mindset and focused on delivering something hoping to solve a problem, but we didn’t talk about outcomes, only outputs. A product-thinking approach would force us to ask different questions, for example:

• How could we use this Sprint to learn from our customers?
• How might we find a solution that drives the desired outcome?
• Which experiments could we run this Sprint to uncover our blind spots?

Our only question was: “What can we deliver this Sprint?” We assumed we had to deliver something and didn’t reflect on how we could learn what mattered.

Even though we may strive to have a product thinking mindset, our brains are tricky and continuously push us back to our comfort zone: project thinking.

It’s easier to think about delivering solutions than solving problems. The danger lies in assuming impact without evidence. The longer you focus on delivery, the more disappointing your results can be. 

I’ve been there more often than I’d like to. The challenge is helping our persistent brain move from outputs to outcomes. This leads me to two common traps almost all teams fall into.

2. Commitment Escalation

How often do you get yourself investing in something that is not working? Let me give you a classic life example. 

Consider you’ve been in a relationship for three years, and you’re both unhappy as you realize you want different things in life. However, you’ve been invested in it for years now. You wonder if it makes sense to break up, but you don’t take action, and you keep wondering about that for years and years. Eventually, you get married and have kids. After ten years, you finally decide to break up, but now it’s an expensive divorce. 

Most people wait until it’s unbearable to take action. The more involved you are in something, the more you’re willing to scale your involvement, even if it makes no sense. This is called commitment escalation.

In our chatbot scenario, we had nothing to show after two Sprints and no learning from real end-users. In other words, we were flying blind. Yet, we were deeply invested in it. Instead of challenging our actions in connection to our objective, we invested more time in it. We believed it to be the right thing to do, though we lacked evidence to back us up. 

3. Confirmation Bias

Along with commitment escalation comes confirmation bias. Nobody likes being wrong. It can be embarrassing and painful. The trap is that we often search for reasons to prove ourselves right instead of wrong. And guess what happens? You’ll find enough reasons to make you feel right and confirm that you’re on the correct track.

I think I don’t need to tell you that we fell into this trap, too. After two Sprints without anything to show, we had to be sure we were on the right track. Otherwise, management would get mad at us. We put a survey on our website to identify interest. We asked, “We’re building a chatbot to help you solve your issues instantly. How would you view that?” Obviously, customers said it’d be perfect for them and even mentioned they dislike talking to customer service agents. A chatbot would do the job perfectly. We confirmed we were right.

When I reflect on this example, it’s embarrassing. What a dumb way of creating surveys. Learning from this: never ask customers if they’d like a solution. They will potentially say yes. Yet, customers surprised us once we went live: almost nobody understood how to use the chatbot, and they even complained to our customer service that our chatbot was useless.

Great teams are aware of these traps. They are humble to reflect on whether or not their actions contribute to desired outcomes. And when they realize they are set to fail, they are brave to change their direction and immediately drop their investment.

Dealing with Sprint Carry-Overs

Alright! I’ve just named common pitfalls teams often face. Dealing with carry-overs requires you to keep these three pitfalls in mind. Once you’re aware of them, use them during your Sprint Planning. Here’s my recommendation:

1. Start with why: Answer as a team. What makes this Sprint valuable?
2. Sprint Goal: What should we achieve by the end of this Sprint? Be careful with this question. Ensure you don’t use the verb “deliver” instead. This would set you in a project-thinking mindset.
3. Sprint Backlog: What will we do to achieve the Sprint Goal? Define which activities the team will focus on to reach the defined Sprint Goal.
4. Carry-overs: Analyze your carry-overs. How do they help you with your Sprint Goal? If they’re unrelated to the Sprint Goal, you should refrain from continuing to work on them. You will be tempted to continue without challenging, but remember the traps we discussed—project thinking, commitment escalations, and confirmation bias. Do what contributes to reaching your goal and remove any distractions.
5. Critical Carry-overs: Sometimes you’ll face carry-overs contributing to the Sprint Goal you want to achieve. When that happens, talk to the team to agree on what can realistically be delivered in the Sprint. I encourage teams to refine the carry-over based on the current learning to ensure everyone is on the same page. This should be the exception and not the rule.

It’s not because you’ve worked on something that you must continue to work on it. Many teams assume carry-overs must be finished. I challenge that. Take ShapeUp as an example: Every cycle lasts six weeks. The team has this period to solve the agreed-upon challenge. If they fail to deliver, they won’t continue to work on it unless it gets prioritized for a new cycle.

I encourage teams to create learning opportunities instead of breaking down solutions into several Sprints. Every Sprint should create chances to learn. If a solution takes more than a Sprint to yield learning, it’s a clear sign you’ve been trapped into project thinking.

The longer it takes for you to learn, the more dangerous your solution becomes.

I learned that the first loss is always the smallest. Don’t keep doing something just because you want to get it done. If you don’t like a book, stop reading it. If the features don’t help you with your desired outcome, retire them. 

Never search for reasons to prove you right; you’ll likely fall into confirmation bias. Search for reasons to prove you wrong. This will help you be open and learn instead of wasting your valuable time on fool’s gold.

Final Thoughts

I used to perceive carry-overs as bad planning. I thought I screwed up with the team during the Sprint Planning. But in time I realized my mind was too focused on project thinking. It’s impossible to precisely predict what the team can deliver in two weeks because software development is complex. 

The beauty of Sprints doesn’t lie in breaking down work into smaller cycles, but in increasing the learning speed. We miss learning opportunities when we blindly accept carry-overs and work on them Sprint after Sprint. Every Sprint should be a different story. Scrum teams will create value faster when they:

• Focus on learning what drives the desired outcome
• Put their energy into achieving Sprint Goals over commitment to features
• Collaborate to uncover the unknown
• Move from project thinking to product thinking
• Learn how to escape from commitment escalation and confirmation bias

Bad Scrum teams deliver more features after every single Sprint. Good Scrum teams create value every single Sprint.