Why Sprint Carry Over is a Problem

In today’s blog, I’m taking a hard stance on something that is more common than it should be, which is carry over from one iteration to the next. 

Sprint carry over occurs when work is not finished in the iteration where it was planned. Some may not see carry over as a reason for concern, thinking that it will get done at some point so the when doesn’t really matter. But in reality, carry over can have some real negative consequences and be a sign of some hidden problems.

So, let’s look into why sprint carry over is a problem, what it is signaling for us, and also how to fix it so it doesn’t become a habit.

If you’d rather watch a video than read, check out the live class I did on this topic!

Why sprint carry over is a problem

If you are operating in iterations or sprints, release planning requires that you hit certain scope on certain dates. So, the obvious issue with carry over is that you are now late on the work you promised would be delivered. 

It’s not uncommon for people to either feel that they can just fix things later and aren’t worried about being late, or they know it’s a problem so they rush to complete the carry over and get the work done. But even when the carry over isn’t detrimental in itself, it is signaling other problems that we might be having and not paying attention to.

Think of iterations as the container for your focused work and a tool for achieving compromise with stakeholders. Broken commitment equals broken trust. 

Iterations are a tool for compromise and commitment between you and your stakeholders. They understand that you will do focused work, uninterrupted by them, and that they can provide feedback and ask for new modifications at the end of every iteration. However, if you can’t deliver on your commitment, the stakeholder can no longer easily pivot. If you can’t use this tool properly, you are diminishing the trust. This broken commitment should not be taken lightly. It can give stakeholders a gateway to ask for a ton of work upfront thinking that only some of that work will get done. It is a recipe to become overloaded on your end too. 

Think of iterations as a tool for timely feedback and quick learning. Iteration equals consecutive approximations. No feedback, no learning.

Carry over means you aren’t receiving timely feedback on the things you create. A lot of people don’t understand agile in practice, thinking you can get feedback any time, anywhere. You don’t want to be disturbed all the time though by receiving input. It allows people to keep changing their mind and things never get finished. Iterations come as a tool for you to separate and indicate when it is a good time for feedback, providing some much needed structure.

Not all business models and processes benefit from using iterations, or sprints. Don’t fall for the “we must use Scrum to be agile”.

If it doesn’t work for you, don’t force it. Scrum isn’t right for everyone. Sprints are a powerful way to fend off distraction, but only if used as intended. Make sure you are using this tool in a way that makes sense. 

When carry over is a problem

Some people may not think sprint carry over is a problem if it rarely happens, but it might be signaling a larger issue.

To know when carry over is a problem, consider:

How long?

Is the carry over encroaching on half of the next iteration or only a couple of days? The impact of the carry over will also depend on the length of your sprints. If your sprint is 10 days and you spend 2 days on carry over, you just used up 20% of your time.

How much?

How much carry over do you have right now or do you usually have? Is it just one unfinished story or 5?

How often?

Does it happen every single iteration? If so, it’s now your pattern to blow up sprints and carry over. Or did it just start happening? If so, what changed?

The problems that carry over can signal

Carry over can be the consequence of some hidden problems that need further investigation to resolve.

Carry over signals problems like…

1 – Overcommitment. You must be able to understand and abide by your capacity. Overcommitment is not outside of your control so spend some time figuring it out. High performing teams require this understanding.

2 – Breaking the iteration principle. Maybe you don’t respect what an iteration is, meaning you don’t respect the commitment between you and the stakeholder. 

3 – Accepting work you don’t understand. If you start before you are ready, you can’t know when you will finish it. You must streamline your process of asking the questions ahead of time so you have enough understanding of the scope to go about the work.

4 – Not adjusting scope. Don’t use the iterations as the constraint and the scope as the thing that is elastic. The scope is not fixed, the date is. 

5 – Not renegotiating through change. If you commit to a sprint and something changes or there is a severe disruption, you have to renegotiate. Don’t just push through.

6 – Not understanding/respecting your SDLC. You might not understand or respect your process of work. All factions of the team need to interact. 

7 – Poor collaboration. Every process will have bottlenecks at some point, but the team needs to be able to cooperate and communicate through them. 

Ideas to fix the carry over problem

Remember, before you can do any fixing, you have to do the investigative work. You have to know the why before you can implement any solution.

1. Separate capacity. Do some sort of administrative work with your team. Understand that capacity is something to be managed. Learn the strengths of team members and disperse capacity as needed. 
2. Say NO upfront. This sounds simple and of course it isn’t. The reason why many people won’t say no is because they don’t want to disappoint. All this leads to is disappointment later on when you can’t deliver. Disappointing to a NO upfront is better for your relationship with your stakeholders. 
3. Separate delivery from investigative work. When you commit to deliver something in an iteration, be sure that it is ready for real feedback. THis is not the same as spending an iteration thinking through and trying things. You can do this and you should, but they are distinct.
4. Seriously understand how you produce work. You must have a serious understanding of what it takes to produce your work – the tech, conditions, constraints, strengths and weaknesses within your team. Check out my blog post about continuous improvement!
5. Use synchronization to constantly make decisions. Use your daily huddle or regular meetings for decision making, not status reporting. Make smaller, regular decisions that move things forward. Keep it productive. 
6. Don’t use iterations if it doesn’t suit your model. If you can’t commit to this kind of structure, don’t do it! 

Remember, improvement is impossible without change. Don’t ignore carry over! Sprint carry over is a problem so learn from it by adjusting your behavior or a process.