It happens – the team was working really hard on something but in the end they weren’t able to finish all the work.

What do you do with the work that’s left?

Do you take it into the next Sprint? Do you put it back into the Product Backlog? Do you re-estimate it?

And more importantly, how do you actually avoid it?

All of these are great questions. Let’s answer them!

In this video (and this article) we’ll talk about carry-over – the plague amongst many Scrum Teams.

It’s a pretty fitting topic for the beginning of the year, don’t you think?

It’s the time where everyone is making resolutions, usually, inspired by all the things we wanted to do last year but never did.

Our personal carry-over.

Let me share some practical advice on what to do with it.

(I mean, not your personal carry-over, but your Scrum Teams carry-over from a previous Sprint.)

Watch the video or keep reading

But before I do, a quick reminder to like this video, if you like it, of course, to comment down below, and, of course, if you are subscribed yet – subscribe!

Also check out my guides and templates in my store.

Is it bad to have carry-over?

Hmmm… yes, and no.

It is bad when it becomes a habit, and no one really cares about having carry over.

The team just knows that each sprint they’ll have some undone work that will pour into the next sprint.

This attitude is not ok.

We should not accept carry over as a given.

If we do, not only do we undermine the importance of a usable working product – the pinnacle of Scrum, but we also remove the sense of accomplishment from the team.

It is a terrible feeling to never see progress, or feel like no progress has been done. It is demotivating.

The most passionate developers will stop caring about the work if they never see any progress.

And that is exactly what can happen if carry-over becomes a given.

On the other hand, having carry over is not bad in the sense of the team performance in the long term.

We work in a complex business environment, and it means that we’ll uncover more information as we start working which may drastically impact how much work we are able to finish within the same period of time.

The Sprint Backlog may, and most likely, will change during the sprint.

So if occasionally your team ends up with carry-over, don’t ring alarm yet. This is absolutely expected.

In the end, we have a set amount of time in a sprint, and while we cannot know for sure how much work exactly we’ll be able to finish, we should do our best to get to “Done” every sprint!

Let me give you an example of ScrumMastered sprints.

Every sprint, which is a week for us, me and my team committed to producing one video and several short pieces of content.

Sometimes, we’ll post every working day of the week in addition to a 20 minute full-length video because we had great ideas, and enough time.

And sometimes, we’ll only post a couple of times, with a 4-minute full-length video.

Do we plan on posting every day and produce longer videos every week? Yes!

Can we always do it? No.

But we still deliver a Done increment every Sprint that provides immediate value to you – my audience. Sometimes we are a bit late, but that doesn’t happen that often.

However, if we would end every week with a half-baked video that is not ready to be posted at all, well, that wouldn’t do.

For example, if we took a piece of content that is too big to complete within one week, then, you don’t get any value, and we don’t have anything to show for our work.

To re-estimate or not to re-estimate?

So you ended up with carry over at the end of the sprint.

The big question is – do you re-estimate the work left or not?

I believe re-estimating is the best approach here.

It will give you a much better understanding of how much work your team is able to get to Done.

Done is all that matters. It doesn’t matter how much work you have in progress.

Would it give you value knowing that it is almost done and I have a script and a half-edited video? You can’t use it, so you don’t receive any value from it.

Re-estimating will allow you to collect much better metrics that are more realistic for your team.

Otherwise, if you keep the original estimate, it will artificially increase your velocity and may lead to the team over-committing.

Now, I know what you’re thinking: “but we did the work! will it be lost then?”

The work is not lost. And the time spent on it isn’t lost.

If the concern is that all of those hours spent on this work will not be counted, then the answer is simple.

Every sprint is the same length. Which means that every sprint you spend the same amount of hours on the work. So we know how much time was spent – this is not what really matters for your performance.

I may be spending days and days creating a video, but if I have nothing in the end, it all was just busy work.

And let’s not go into the topic of over-time – this should not be a practice, and should not be encouraged in general.

That’s a big topic, I may make a video about it later.

Next Sprint or Product Backlog?

Ok, the work is re-estimated and ready to keep going.

But wait.. do we automatically move it into the next sprint so that we can finish it, or does it go into the Product Backlog?

Well, let me quote the Scrum Guide (because why wouldn’t I):

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Just because you have already done some work on something, doesn’t mean it is more important than everything else in the Product Backlog.

There might be other work that becomes much more important, and you don’t want to waste your time on something that no one needs.

Here at ScrumMastered we create lots of learning materials in many different forms apart from videos.

I have a few things that I have started working on because at the time I thought they would be great.

But because I never finished them, in the meantime other opportunities emerged and I switched to them instead.

It pains me a bit to know that I have lots of unfinished content to share, but it would pain me more to spend days or even weeks on completing it only to find out that no one needs it.

Another important point to consider here is that if you always just automatically put carry over into the next sprint, it removes the sense of urgency and the focus from getting something Done.

If you can just finish this work next sprint, why even stress yourself with it during this sprint.

That will be a problem for later, right?

How to avoid it in the future?

And then it comes to this question: how do you prevent carry over from even happening at all?

You will never be able to eliminate it.

Once again, we work in a complex environment with complex products. Things happen.

But here are a few strategies you can use to help your team reducing the probability of carry over.

1. Sprint Planning

Basically, learn to plan better.

Which reminds me of this meme…. but that’s not what I mean.

What I mean is to always take some extra time to review the work taken into the Sprint in more detail during the Sprint Planning.

Ask the team:

• What do we need to do exactly to accomplish this product backlog item?
• Are there any dependencies we need to be aware of?
• Can this product backlog item be split into smaller pieces of?

And for every item you bring into the Sprint Backlog ask: how confident are we that we will be able to finish this work within this sprint?

I would recommend to fill in about 75% of the team capacity during the Sprint Planning.

If all the work gets finished early, you can always bring in more later.

If you need help with running productive Sprint Events, btw, including the Sprint Planning, of course, check out my Scrum Master Startup Guide in the store.

2. Splitting work

Speaking of splitting work. This is another strategy you can (and should) use.

This is a skill that will take some time to develop to understand how to vertically slice work into smaller batches.

The first thought would be to split the work by phases: we’ll code in this sprint, and we’ll test in the other.

Well, if you just have the code, you still don’t have anything Done, and hence, your customers and stakeholders will not receive any value from it.

It would be same if I decided to script and film my video in one week, and edit and upload it on another. You don’t get any value after the first week, so what was the point of splitting it anyway?

What I can do instead, is to consider to cut my video shorter so that I have time to complete everything in one week.

You should do the same with the team. Think of how you can split the work

I recommend looking into S.P.I.D.R. approach to splitting work from Mike Cohn at Mountain Goat Software.

It always worth the time to discuss how bigger and riskier work items can be divided into logical valuable increments.

3. Updating your Sprint Backlog

And the last strategy I have for you is to remember that the Sprint Backlog is not set in stone.

The only thing that doesn’t change during a sprint is the Sprint Goal.

The Sprint Backlog is updated throughout the Sprint as more is learned.

As soon as it is identified that a work item would not be completed within a sprint, the team needs to make a decision.

Here are a few questions to ask:

• Is there a way to fully complete a part of this product backlog item this sprint, for example, only certain acceptance criteria?
• What else in the Product Backlog can we take instead, that is small enough to be completed this sprint?
• What other useful work can be done, for example, fixing some bugs or tech debt?

In the case with ScrumMastered, I might have planned to do a video on a difficult topic that requires some additional research, but after a couple of days I see that I won’t be able to finish it.

Then I look for other easier topics I can pick up and complete faster.

Let’s summarize what to do with Sprint carry over:

• Having carry over is not the end of the world as long as it doesn’t turn into a habit and accepted as a given.
• It’s best to re-estimate the work based on what is left to have better metrics.
• Carry over doesn’t automatically ends up in the next sprint, and instead should be re-prioritized against everything else in the Product Backlog.
• You can help your team to avoid carry over by filling in only 75% of their capacity in the Sprint Planning, by splitting the work into smaller pieces of value, and by updating your Sprint Backlog as soon as you learn that that Product Backlog item cannot be completed this sprint.