Carry-overs are good when you use Scrum

Sprint Goal Jul 2, 2020

Completing the whole Sprint Backlog should never be the goal

“How many carry-overs do we have from the previous Sprint?”, a dreaded question often asked during Sprint Planning. When the answer is zero, everybody smiles and rejoices. We did it! YEEHAWWW!

When there is at least one carry-over Backlog Item to the next Sprint, the team is disappointed and feels like they’ve failed. Are carry-overs something dirty, to be prevented at any cost? Or are we treating carry-overs the wrong way?

Should we really be aiming to have no carry-overs to the next Sprint at all?

I believe carry-overs are good, as not finishing Sprint Backlog Items may be necessary to meet the Sprint Goal. Carry-overs are what allows the Scrum Team to be flexible and adaptive. Carry-overs are the mark of a team that made the right decisions during the Sprint.

These statements will probably surprise you and sound counter-intuitive, so allow me to explain.

The three parts of the Sprint Backlog

According to the Scrum Guide, the Sprint Backlog consists of two parts:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the Product Increment and realizing the Sprint Goal.
  1. The set of Product Backlog Items selected for the Sprint
  2. The plan for delivering the Product Increment that meets the Sprint Goal

However, the Product Backlog Items selected for the Sprint can be further broken down in two parts, ultimately resulting in three different parts:

  1. Sprint Backlog Items that relate to the Sprint Goal (commitment)
  2. Sprint Backlog Items that do not relate to the Sprint Goal (no commitment)

Since the team only commits to building a Product Increment that meets the Sprint Goal, you can see Sprint Backlog Items that do not relate to the Sprint Goal as Stretch Goals.

If the Sprint Goal is going well and we’re not encountering unforeseen complexity that needs to be dealt with a higher priority, we’ll also finish the Stretch Goals. If we encounter problems that we did not anticipate, these Stretch Goals are abandoned in favor of meeting what matters most: the Sprint Goal.

Let me give you an everyday example of this principle in action. Imagine you are at the supermarket to buy some groceries which are necessary to prepare dinner for friends at your house. On the way there, you receive a message from your partner:“If you have enough time, can you also buy some bike lights on the way home from the bike shop a few miles away?” The key part here is, if you have enough time.

If you bought the bike lights and then skipped buying groceries due to lack of time, your partner, and your friends, would be extremely disappointed. What matters most is buying the groceries for dinner, as without groceries, there is no dinner. The bike lights can wait and are not important for today. If you bought groceries and the bike light, but you would be home after the guests arrive, then that would be unsatisfactory as well.

If you wouldn’t buy the bike light, but you were able to bring all necessary groceries for dinner, nobody would be sad about it. The bike light is a nice-to-have, only to be done if you have sufficient time, and definitely not at the expense of being able to have guests over for dinner or being home on time to cook dinner.

It’s the same with Sprint Backlog Items that do not relate to the Sprint Goal. You only finish them, if you have the time to do so, and not at expense of being able to meet the Sprint Goal.

If you use the Sprint Goal lens when looking at the Sprint Backlog, what does this mean for carry-overs? If those carry-overs are not related to the Sprint Goal, it means you dropped them to ensure you are able to complete the Sprint Goal. It means you didn’t go fetch the bike light, to make sure you have enough time to buy groceries for dinner. This is definitely the right call and something to be celebrated!

It’s the flexibility that a Scrum Team needs to be able to inspect and adapt during the Sprint. Without this flexibility, Scrum’s empirical foundation shakes at its core. The team gets stretched too thin between fetching the bike light or getting the groceries, putting all of them at risk as a result.

Teams will never make perfect plans or make accurate estimates, as they are always limited by the beforehand knowledge. To deal with complexity and uncertainty as it appears, flexibility during the Sprint is necessary. In such cases, the plan and details must emerge during the Sprint.

Adaptation, dealing with uncertainty and complexity as it appears, requires space and flexibility in the Sprint Backlog. This is achieved by having the Sprint Backlog contain items unrelated to the Sprint Goal, or by planning with limited (lower) capacity. You will only pick up these Sprint Backlog Items unrelated to the Sprint Goal, if time permits and meeting the Sprint Goal is a certainty.

A word of caution though: working on Stretch Goals should never come at the expense of doing work on the Sprint Goal. The Sprint Goal is what ultimately matters most. You don’t want your team to be busy with Stretch Goals to such an extent that work on the Sprint Goal becomes idle and awaiting feedback. It’s a delicate balancing act and with inexperienced teams it may help to only pull additional work in once you’re sure the Sprint Goal will be completed.

Carry-overs grant the flexibility you need to meet the Sprint Goal

Carry-overs to the next Sprint, as long as they do not relate to the Sprint Goal, are something good. Carry-overs indicate the team acted and prioritized in the moment, in order to protect completion of the Sprint Goal. When there are carry-overs related to the Sprint Goal, the problem is not the carry-overs. The problem is that the team was unable to meet the Sprint Goal. What problems or challenges did we encounter that resulted in not being able to meet the Sprint Goal?

If you make the Sprint Backlog a commitment, then that means that the Sprint Backlog is more important than the Sprint Goal. To be able to deal with reality as it unfolds, you should never plan at full capacity. And because the Sprint Backlog is flexible, when you’re in the clear with the Sprint Goal, you can always drag in more Sprint Backlog Items into the Sprint.

When you don’t complete the additional Sprint Backlog Items, but do meet the Sprint Goal, you can still be proud you made the right call during the Sprint to meet the Sprint Goal, at the expense of completing those additional work items.

When you work this way, the Sprint becomes a hybrid of a per Sprint commitment (Sprint Goal) and a pull-based system (Stretch Goals that are pulled in during Sprint). If you complete those Stretch Goals together with the Sprint Goal, then you have an extra reason to celebrate.

Look at this way: just meeting the Sprint Goal already puts enough pressure on the team. Don’t burden your teams with the additional pressure of completing everything that was originally present in the Sprint Backlog, as it only serves to put what matters most in the Sprint at risk: the Sprint Goal.