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?

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

I don’t think having unfinished tests at the end of a sprint is a good idea. At the end of a sprint, everyone is a tester. “End of the sprint” might mean just the last five minutes if everything is automated. Most likely it isn’t and everyone needs to focus on getting work complete during the sprint. Even if that just means that programmers spend the last day or two automating tests or creating tools to facilitate automation, that is better than allowing the programmers to get two days further ahead each sprint.

Posted by Mike Cohn on 2016-05-31 08:44:02

Thanks for a great post Mike.

What I have often seen in our teams is that in a 2 week sprint, we often have 1-2 stories that are finished with the development towards the end of the sprint, hence remain unfinished with tests and spilled over to the next sprint.

This brings up the case that essentially these stories are "unfinished" and cannot be treated as probable shippable product. We thought about a few approaches to avoid this unfinished work. One being reducing the dev days by a day or two. But this didnt quite work and made the developers quite unhappy. Then we changed the definition of done. We introduced Dev Done. We started testing one sprint behind. But that forced us to demo stories without being tested, which I was not happy and convinced with. We started getting bugs of previous sprints when the team was focused on the current one.

What is your opinion on the "unfinished Tests" at the end of the sprint ?

Posted by Malvika Sinha on 2016-05-30 07:03:36

Hi Amit—

There’s not much you can do about the random occurrence of a team member being sick during a sprint. But for other things, consider not planning the sprint as full so you have room for more tasks that will be discovered during the sprint. You can also try “thinking harder” during planning. But even so, there will also be tasks that will be discovered during the sprint as well as tasks that will expand during the sprint. So thinking harder can be time consuming (i.e., wasteful) and only helps a limited amount.

This topic is also addressed in a couple of videos in chapter four of my Scrum Repair Guide video course, which is on Front Row Agile at https://www.frontrowagile.com/...

Posted by Mike Cohn on 2016-02-28 12:18:59

Hi Miike,

We mostly leave 2 to 3 task of a story unfinished every sprint, which We take to next sprint.Reasons identified are sudden health issues with employee which is not occurring so much. But the most important and happening repeated is:

Task decision - In Sprint planning few tasks are not added but is added at later stage which are identified as impediment during Scrum meetings, or while completing a task.

Please suggest How can We handle such situations?

Posted by amit sharma on 2016-02-28 05:34:24

Great! I would love to hear about this. Can't wait for the post.

Posted by Michael on 2016-02-02 13:21:34

Michael: Also you can use a prediction interval, which is an even better statistical technique and completely gets rid of the issue you’re describing. The math is slightly more involved so I haven’t written about it before, but I’ve been asked to blog about it so it’s on my list to write about it.

Posted by Mike Cohn on 2016-02-01 20:36:21

Don’t have large stories.

Posted by Mike Cohn on 2016-02-01 20:22:57

Hi Mike,

The main issue I have with adding all of the story points in the sprint that it was finished in is the reporting and how accurate the 90% confidence interval algorithm (https://www.mountaingoatsoftwa... is. We use story points to forecast the range of stories that can be completed in X sprints. If we allow the story points of large unfinished stories to be committed to one of sprint and finished in another sprint, we're artificially creating outlier data which in turn increases the 90% confidence interval algorithm range. Especially if 80% or 90% of the work was done in the sprint that it was committed in. It essentially creates under-performing data in one sprint and over-performing data in the next. Most people will think that averages will fix this discrepancy; well sure it will but it'll take 8 iterations before you're able to drop 1 outlier from each side. What I'm getting at is that we're using Story Points to forecast future work (minimum and maximum story points competed in X sprints) but the inaccurate data will compound the inaccuracy over more iterations. For example, lets say my range is 20-50 story points since I had to put the incomplete story points from the 20 user story iteration to the 50 story point iteration. I'm forecasting 10 iterations out so my story point range is 200-500. If I would have put the story points in the sprint it was worked I would have had an iteration range of 30-40 which comes out to 300-400 10 sprints later. That's a difference of 200 story points over 10 iterations which comes out to about 5 iterations of work. That's a startling amount of inaccuracy. Can you explain to me why why we accept this amount of inaccuracy instead of just adding points where they were worked? Thanks!

Posted by Michael on 2016-02-01 20:21:33

Thanks, Akmal.

Anything is possible. But I’ve never seen a team member in one sprint start to completely re-develop what was mostly implemented in the prior sprint. And if they did, I’d sure hope someone would catch that within a day or two of daily scrum meetings.

I really don’t think, though, that this is something that needs a rule one way or the other. It’s really into the category of personal and contextual preference. I’ve seen it done both ways plenty of times and have seen no evidence that one approach is better than another.

Posted by Mike Cohn on 2015-11-11 10:22:34

Hi Mike, Thank you for the wonderful post. I agree that an unfinisheditem shouldn’t be moved to the next sprint automatically without productowner’s approval. Regarding “splitting or carrying forward” the unfinished work(specially when part of the functionality is developed), your recommendation was“Don’t rewrite the story. Everyone is used to it as it’s written.”

I’m afraid that in this specific scenario a team member maynot remember that part of the item was completed in the earlier sprint andmistakenly he/she starts developing the whole functionality again in the nextsprint.

Do you think this is likely to happen? Or do you agree thata configuration or a tracking system should be in place in order to tag the item as partiallycompleted?

Posted by Akmal Siddiqi on 2015-11-11 00:23:52

Hi pluaces—

Having a small “collector” product backlog item is a common approach that I’ve seen work well. Since it’s working for you, I’d definitely stick with it. And I definitely wouldn’t worry about going back and re-estimating old product backlog items.

And I’m glad you find the blog helpful. Thanks for letting me know.

Posted by Mike Cohn on 2015-10-25 11:58:41

Hi Mike,

At the end of the sprint is yet another cause for "remaining work". Stakeholders may come up with feedback/changes for the PBI you have been working on and want those changes done in your next sprint.Our team became quite experience at planning and we hardly ever have huge chunks of remaining work. It can be the 5 to 10% of a PBI tops.

The approach we normally take is to add a PBI to the backlog to bundle remaining work and feedback and re-estimate that new one at sprint planning.

We do not worry too much about going back and re-estimating PBIs, things average over time as you mentioned, and after a few sprints you know what your velocity is.

Any comments/suggestions?

Many thanks for your blog, really insightful.

Posted by pluaces on 2015-10-23 09:06:05

Thanks, Bob. Great points! Thanks for sharing this.

Posted by Mike Cohn on 2015-10-20 20:24:24

I couldn't agree more, Mike, that the current emphasis on lean is concerning. A state of flow is enabling, but it is not an end in itself. Just because Toyota wouldn't use Scrum on an assembly line doesn't mean lean can displace Scrum practices. With all the hype, it's easy to forget that lean is a child of assembly-line manufacturing.

Two key Scrum pillars that I think are often lost in the lean hype are collaboration (as opposed to coordination) and intentional delivery events (as opposed to deliver-when-ready). The former fosters the creativity our software work products need, and the latter insures that we accommodate the ability of our customers to receive what we produce.

Posted by Bob Lieberman on 2015-10-20 16:15:27

Hi Piotr—

I agree—in almost all cases, product owners will want to finish the remaining work in the next sprint. I think, though, it’s important to acknowledge that a conscious decision about that should be made. It’s just a brief millisecond “yep, I want it” thing. I just don’t want work to *automatically* roll forward.

As for “committed” and “optional” work, it’s interesting. I see teams have very different responses to that. It’s often called a “stretch goal.” And a team will have the work they commit to and then a “stretch goal” they’ll do if time permits. My *personal* reaction to stretch goals is that I feel them like a crushing weight. I have a mental screw loose and can’t distinguish between the real commitment and the stretch goal so I will try to finish all of it. (This isn’t healthy. It’s just who I am.) Some teams are like me, though. And for us, this is a really bad idea. For other teams (those perhaps who I can say have a healthier view of “stretch goals”) it can be a great idea. So it’s something I recommend for some teams. But it’s the type of thing that makes me really nervous when I see a company say “All teams should define a firm plan and then a stretch goal.” Eek! No, that’s going to be bad for teams with people like me on them.

Posted by Mike Cohn on 2015-10-19 23:49:13

Hi Mike,very interesting problem, that i am sure has a lot of good solutions. Therelated one is how you handle finishing the unfinished worked.

I am running projects for something like 10 years, and in 99% cases Product Ownerwants to finish the “remaings” in the next sprint – as soon as possible. Andthe team of course as well. What I see quite often is that at the end of thesprint teams are saying it is almost done – few hours left, and then need few moredays to close it properly. There are few reasons for that, two being my favorite– we tend to be even more over optimistic at the end of the sprint and therecan be few disruptions between sprints. If you have few teams, it is not thatuncommon that you need to have additional regression, integration tests etc.Add to it the usual planning, demo, retro and you can end up with team that isnot able to focus that much on getting their work finished.

Of course there could be few approaches – move the end date, move planning/reto/demo, rearrangethe meetings, make few people less involved in these meetings. They are notalways possible, especially when you have few teams and you want to keep theirwork in sync. Also my feeling is that if you do it can easily become a habit.

The approach I quite like is to split the sprint goal in to two – committed andoptional. It has probably mostly the psychological effect - if you are havingproblems only with optional, you are less likely to do shortcuts. It is also okto park such item to do something else to help finishing the sprint. Peopletend to not treat the disruption as so painful is such cases.

The side observation about having often more than a bit of unfinished work is that therecould be other problems – hidden impediments or disruptions, issues with requirements,quality, estimation or process ( to heavy or to lite J). And sometimes the answer to it is more “Kanbanlike” approach.

I wonder if there are other ideas to keep disruption to minimum and finish unfinished asquickly as possible.

Piotr Szatkowski

Posted by pszatkowski on 2015-10-17 17:10:55

Agree, no panic required but, enough to alarm to trigger some discussion in a retrospective.

Posted by Nick Xidis on 2015-10-11 08:07:15

Good point on the value of a consistent stream of small victories; good for the team, good for the product owner too. No one likes to work hard and not see a win.

Posted by Nick Xidis on 2015-10-11 08:00:20

Thanks, Vishant. I like your suggestions. Anything that brings visibility to the issue can help a team.

Posted by Mike Cohn on 2015-10-10 23:31:51

Hi Nick—

Work being carried forward is definitely cause for “some level of alarm.” But even on a great team it can certainly happen occasionally. The real problem is—as you say—when it becomes the norm over time. That is absolutely one of the worst habits I see Scrum teams fall into.

Posted by Mike Cohn on 2015-10-10 23:30:57

Great topic Mike.

Not sure there's an answer for every team but, I have found work carried forward is evil and cause some level of alarm. Too often, carried work becomes the norm over time. It's demoralizing and can cause significant friction. In addition, it makes measuring progress very difficult.

I've also noticed that teams that frequently carry work forward tend to not do much reflection on their process.

Posted by Nick Xidis on 2015-10-09 11:33:31

Hi MikeThis is very good article. Your blogs give insightful and very helpful to SCRUM master.We encourage team to finished work with in a sprint. Due to some reason , if work is not completed then, team take care in next sprint.To minimizing unfinished worked we do few things as follows : 1. we do tagging on each card with date (ie development done and QA done). This gives team more visibility and it help team. 2. While doing sprint planning we also look at the team availability during the sprint.

Posted by Vishant Sanghavi on 2015-10-09 06:04:58

Ian, thank you for your comments. Yes, in theory, we would not worry about accounting for story points. However, practically speaking, we must know how much effort (tracked in Story Points) is spent on a feature just to understand whether it really adds value to the end customer.

Posted by Santosh Shaastry on 2015-10-08 21:29:18

You’re welcome.

Posted by Mike Cohn on 2015-10-08 21:28:30

Mike, Thank you for the link. Have a better understanding now.

Posted by Santosh Shaastry on 2015-10-08 21:26:55

So true. Sprint switches should definitely have and retain their meaning. Teams ought to show only items they have *completed* (== done done) since the last one.

Posted by Martien on 2015-10-08 09:47:19

I think a team should strive to complete what they choose to do in a sprint. I do not think sprints should become meaningless calendar dates.

Posted by Mike Cohn on 2015-10-08 09:33:41

Fully agree. Yet, even with ‘lumpy’ flow, handling work left at the end of a sprint is a non-issue, TMO. DoD secures stuff gets done done, right?

Posted by Martien on 2015-10-08 09:32:31

Well put, Scott.

Posted by Mike Cohn on 2015-10-07 11:30:12

Hi Martien—

Yes, I largely agree. For some teams work can be thought of exactly as you describe and work is largely about flow through their process. For other teams, though, the work is more about innovating rather than flowing. Those teams will have “lumpy” flow.

We’ve lost a lot of that in Scrum over the years with the emphasis on lean principles, on finishing everything every time, on short sprints, etc. It’s important to recognize that not every project / every team is in a situation of predictable work like this.

Posted by Mike Cohn on 2015-10-07 11:26:18

> If the complete story is carried forward in to the next Sprint and> if we keep the same story points estimate, wouldn't we lose track> of the effort already spent on that story?

In Scrum, you should re-estimate the story and return it to the Product Backlog. It can then be replanned into a future sprint. In effect the story would "shrink" to reflect the work completed thus far.

There should be no partial credit in terms of points. The difference between the old and the new estimates should not be added to the velocity. Instead, the total size of the work remaining in the Product Backlog will be reduced by that difference. That's where progress of some sort can be inferred, if not actually demonstrated...there is less work left to do.

Having said all of that, it is important to remember that we are not story point accountants. There is no value to be found in story points. They are merely tools, as Ken Schwaber has said, for teams to "get their arms around" how much work can be taken on in a Sprint. The real value lies in the increment itself.

I always advocate working with average velocities. So, in the long run, whether that five-point story gets counted in this sprint or the next one won’t really matter.

Posted by Mike Cohn on 2015-10-07 10:58:30

Thanks, Kevin. I’m glad you find the blog posts helpful and that you’re already doing what I recommend in this one.

You’re right about most new Scrum teams being “adventurous.” Almost every Scrum team is overly ambitious and grabs too much in their early sprints. After a team has gotten good, it’s not really a problem to occasionally have some leftovers. But, when starting out, you’re absolutely right that it is an absolutely horrible habit for a team to develop.

Thanks for your comments.

Posted by Mike Cohn on 2015-10-07 10:56:33

I was recently called in to assess the processes of a scrum team and on the surface everything looked fine, but the team was having major quality issues and was not delivering production quality code. When I dug deeper I found that every sprint large amounts of work were being left un-done. They had a 6 sprint release cycle and over 50% of all features for any release were not complete at the beginning of sprint 6. The team was over committing and then working at unsustainable rates to try to catch up. This resulted in a load of technical debt and code that was not production worthy. Every sprint the team was not meeting its commitments.

One of the important aspects of ensuring that work is completed in the sprint is it gives the team small victories to celebrate, and establishes the sustainable rate of work for a team. So in my experience, while it's perfectly normal to have some work escape the sprint (it could even be ok if you are merely bringing in additional work that is not part of your team's original commitment), chronically leaving work unfinished is damaging to your team's morale and product quality.

Posted by Scott on 2015-10-07 10:34:33

BLUF: Handling work left at the end of a sprint is a non-issue.

Reminds me of the ‘overcommit and underperform’ anti-pattern. I prefer ‘undercommit and overperform’. Also reminds me of the pattern “Teams that finish early tend to accelerate faster” (http://www.scruminc.com/wp-con....

You say “it’s quite common”. I say, “teams always have work left at the end of a sprint”. If you follow “Teams that finish early tend to accelerate faster”, you will have all work done before the end of the sprint. Then, what do you do? One of the options is that you pull in new work! Chances are that this newly pulled in work is not finished at the sprint switch moment. TMO, chance is close to 100% that you are working on an item at sprint switch. I see no problem with that at all. Since items are similar-sized (I hope) and just have a couple of days cycle time, the item in progress will get done very soon.

Working like this, the team can mature towards a state of flow, and the sprint concept moves more to the background. The sprint itself becomes subordinate to the sprint switch, and thus the focus shifts to the sprint switch. The sprint switch is ‘merely’ a snapshot moment: were are we in the game, what is our goal, are our tactics still appropriate, how can we go happier, faster, better? A ‘retroprospective’ on product and process if you will.

Also, we can start upping the average number of items that get done every week, as well as lowering the average cycle time (Done time minus Ready time) of each item by using those objective and neutral numbers to generate acceleration experiments.

Bottom line: Handling work left at the end of a sprint is a non-issue.

Thoughts?

Posted by Martien on 2015-10-07 09:02:14

Great post about a topic I wonder about nearly every Sprint ;)Thanks!

Posted by Kevin Wittek on 2015-10-07 04:09:49

A very practical problem addressed in detail. You raise an excellent point about velocity credit. One question: If the complete story is carried forward in to the next Sprint and if we keep the same story points estimate, wouldn't we lose track of the effort already spent on that story? How do you suggest we handle it?

Posted by Santosh Shaastry on 2015-10-07 04:08:00

Thanks for another great read Mike. I always find your blogs to be insightful and very helpful to us Agile practitioners.

I must say as a Scrum Master who has been working mostly with teams who are just starting with following Scrum and being Agile, this is a question I have to deal with often - what do we do with unfinished items after a sprint? I am happy to say we have been doing exactly what you have discussed here in this blog.

One of the most common root cause I have observed in my experience is that new Scrum teams tend to be really adventurous and would take on more work than they can handle. So I would often find myself advising teams to tone it down a little and step back to really think about what they can finish. Lastly I would always emphasize that it is NOT OK to have unfinished items after a sprint. One important thing I make sure to watch out for is teams falling into the habit of always having unfinished work.