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 then 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. Teams earn no partial credit toward their velocity for stories that remain unfinished at the end of the sprint.
But what about the estimates on those unfinished product backlog items? Should they be re-estimated?
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:
- It’s more accurate since some part of the work has been performed
- 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. 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.
Suppose a team has an 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.
