Handling Work Left at the End of a Sprint

It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. This leads to a couple of questions I’ll address here:

• What should be done with the product backlog item itself?
• Should be it split or should it be carried it into the next sprint?
• Should the team receive any velocity “credit” for completing a portion of the story?

First, Be Sure the Item Is Still Important

When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next.

I’m perhaps being overly pedantic here, but the point is that each sprint begins with the product owner making a conscious, deliberate decision about what the team should work on. If there’s unfinished work from the prior sprint, it’s very likely the product owner will want the team to finish that work in the new sprint. But, the product owner should still make an actual decision to do that.

(As a note, let me also say that I’m not suggesting you make extra work for yourself if you are using a tool that would make this difficult. All I’m saying is that work does not automatically move into the next sprint. The product owner must decide if the work is still valuable.)

Splitting or Carrying the Item Forward

When a product backlog is unfinished, teams are often torn on whether they should leave the product backlog item description alone (even though part of that functionality might be complete) or rewrite it to describe just the missing piece.

For example, consider a team building typical print preview functionality in a desktop application. If the team builds everything but the ability to page backward through the pages, it can either carry forward the original user story or write a smaller, replacement story like, “As a user, I can page backward while on the print preview screen.”

I recommend that if you are going to finish the story in the coming sprint, just leave it alone. Don’t rewrite it. Everyone is used to it as it’s written. Assuming it’s still of value to the product owner, it moves forward exactly as written.

However, if the remaining work will be deferred to a later sprint, write a new story that describes just that subset of functionality.

Does the Team Earn Velocity Credit

I always want to take a conservative stance towards calculating velocity. This means that a team should only take credit for work that is truly complete.

So, in the case the unfinished product backlog item is rolling forward to be completed in the next agile sprint, do not take any velocity credit. The team instead earns all credit in the sprint in which the work is finished. Since I advocate working with average velocities anyway, this averages out and avoids the risk of overstating velocity.

But when the team splits the story and puts the remaining subset onto the product backlog to be done in the future, go ahead and take some amount of velocity credit. The team will need to do its best to estimate a fair number of points for the subset of work that was completed. And, even though it did not finish the entire original story, the team may give itself all the original points if it feels the story was larger than originally planned. I’d be reluctant to do that very often. But, it is OK.

Always Look for a Root Cause

Finally, whenever work is unfinished at the end of an agile sprint, the team should take time in the retrospective to consider whether it was caused by something preventable. Sometimes, it’s just bad luck or bad timing, such as a team member becoming ill or a problem being found late in the sprint that could not have been found earlier. But, it’s always worth considering whether there is a root cause and whether something can be done to prevent it from affecting future sprints.

What Do You Do?

How do you handle work left at the end of the sprint? And have you found good ways of minimizing how often you have work left unfinished at the end?