Should You Re-Estimate Unfinished Stories?

As well-intentioned as teams are, it’s really hard to finish absolutely everything by the end of a sprint. A team may have grabbed eight product backlog items (typically user stories), but only finish six or seven of them. The other items are often close to done, but this isn’t horseshoes so close doesn’t count.

But what about the estimates on those unfinished product backlog items? Should they be re-estimated? And should the team get partial credit for the work they did complete? Let’s consider each of these questions, starting with partial credit.

Should a Team Earn Partial Credit?

When a team finishes part of a story, team members often ask to receive partial credit toward their velocity. For example, a team that claims to be half done with an eight-point product backlog item may expect to count half of that—four points—toward their velocity.

This is a bad idea. A team should earn credit only for work that is truly done. In this example, nothing yet meets the team’s definition of done. Work is only half done. Taking credit for partially done work would be like me inviting you over for dinner and serving you half-cooked chicken. It might taste OK now, but you’re going to regret it later.

When a team takes credit for partially complete work, they often overestimate how much is done. There is a joke in the software development profession that says software development projects are 90% done for 90% of their schedule.

This is because developers think they see the full scope of what’s needed and they are truly 90% done with that. But as they work to finish the last 10%, they realize the solution is bigger than they thought—and even after more work they are still just 90% done with the bigger scope.

So a team that says they’re 50% done is perhaps only 40% or 48% or 35% done. Knowing the percentage done is very hard and most of us overestimate how done we are.

Because teams tend to think they are further along than they truly are, velocity is slightly inflated. An inflated velocity feels good at the moment—like my half-baked chicken—a team can tell its stakeholders a nice, big, juicy velocity value. But that inflated velocity will stop feeling good if anyone ever uses that artificially high velocity to predict when the next project will be done.

No Partial Credit

I advise teams to take a stance of no partial credit. No matter how close team members are to finishing a backlog item, they earn no points for it until the entire item is done. This is analogous to scoring a touchdown in American football. In American football, a team needs to move the ball 100 yards down the field, getting into their opponent’s end zone. Doing so earns a team six points (and the opportunity to earn one or two additional points).

Moving the ball 99 yards earns the team…zero points. No partial credit.

The Benefits of a No-Partial-Credit Stance

There are two big benefits to taking a stance of no partial credit. First, team members will seek to work on smaller product backlog items in the future.

A team doesn’t care if their Scrum Master refuses them partial credit on a one-point story. They do care when they can’t take partial credit on an eight-pointer. Most teams will respond to not getting partial credit by splitting items into smaller discrete pieces of work.

Second, when not allowed to take partial credit, many teams resolve to try harder to complete the items they bring into a sprint. That’s great—we want that.

When I refrain from allowing a team to claim partial credit, it’s a double win: the team brings smaller items into their sprints and they focus more on finishing them. What’s not to like?

Having resolved that a team should not earn partial credit for an incomplete product backlog item, let’s turn our attention to whether that unfinished item should be re-estimated.

Re-Estimating Unfinished Work

When a product backlog item is unfinished at the end of an iteration, the team often wants to know if the item should be re-estimated. This is independent from the issue of wanting partial credit. After all, team members reason, at least some work has been done and so the estimate of remaining work may have changed.

In fact, the size of the product backlog item may have increased such that the estimate of what remains actually goes up and is higher than the initial estimate. For example, a team feels like they’ve made two points of progress on a five-point story but also have discovered that there are eight points remaining. In re-estimating partially finished work, it is entirely possible for the new estimate to exceed the original.

But should a team re-estimate at all?

Reasons to Re-Estimate

There are two arguments in favor of re-estimating:

  1. It’s more accurate since some part of the work has been performed
  2. It’s necessary to plan the next sprint

It’s hard to argue with the first point, so I’ll accept that. The second point is where things get interesting. Team members will say they can’t decide how much work to bring into a sprint if some of the backlog items have outdated estimates because they are partially complete.

For example, suppose a team has room for five more points in a sprint. An eight-point story won’t fit. But what if the team thinks approximately half of the eight-point story was finished in the just-completed sprint? It sure seems like half the item could fit in the next sprint. Should it then be re-estimated at four or five points to indicate that it fits?

My opinion is that no, it should not. That is: leave the original estimate alone and bring the item into the sprint if the team thinks it fits.

The argument for resizing the backlog item assumes the team is doing velocity-driven sprint planning. In that approach a sprint is planned by selecting product backlog items whose estimates sum to the team’s average velocity. So if a team has a velocity of 30, they bring in 30 points of work. If they’ve already brought in 25 and the next item is a partially finished item estimated at eight points, that item won’t fit.

But for a variety of reasons, I don’t think velocity-driven planning is the best approach to sprint planning. I far prefer capacity-driven sprint planning, which involves the team simply selecting items one at a time and seeing if the item can be done in the sprint. If they can, they include it and consider another until the sprint is full.

Capacity-driven sprint planning uses velocity but is not driven by it. Teams using this approach aren’t constrained by pulling in exactly what their velocity says they should. And so a team doing capacity-driven sprint planning will take into account the finished portion of that eight-point story when they decide whether the story will fit in their sprint.

Focus on Average Rather than Actual Velocity

In general, teams will do better if they pay a bit less attention to each sprint’s velocity and more to the average velocity of recent sprints. In the approach I’m advocating, a team can feel cheated out of a few points of velocity in one sprint since they aren’t able to claim partial credit. But, since the item is not re-estimated, they’re getting full credit for the work in the following sprint. It all comes out in the end.

In the example of the eight-point story that is half done, the team claims zero points of velocity credit in the first sprint despite doing perhaps three or four points of work. But they get all eight points in the next sprint. This means the average velocity for those two sprints will be exactly as one would expect.

The Sole Time to Re-Estimate Partially Finished Items

Re-estimating partially finished product backlog items is unnecessary work. There is one situation, however, in which it’s advisable. A team should re-estimate a backlog item that is being put back on the product backlog and will not be finished in the next iteration or two. In that scenario it makes sense to determine a reasonable split of the item, give the team some credit for the work done, and return the item to the backlog with a good estimate of the work remaining.

In all other cases, though, a team will do well to not take partial credit and not bother re-estimating, especially if the team is doing capacity-driven sprint planning.

What Does Your Team Do?

What does your team do with unfinished work? Do you re-estimate it? Do you take partial credit? Do you never, ever, ever have anything unfinished? Please share your thoughts in the comments below.

Get Free Estimating Book Chapters!

Get Free Estimating Book Chapters!

Please provide your name and email and we’ll send you the sample chapters and we’ll send a short weekly tip from Mike on how to succeed with agile.

Get my chapters now!


Mike Cohn

About the Author

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 as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.