How to Re-Estimate Unfinished Stories

Have you or your team ever said:

"We didn't finish the work this sprint. We’re going to split the story so we get credit for the work we already did."

"It’s 90% done, just needs some testing. Let's change it from a 13 point to one point for the next sprint."

"Wow, this is way more than five points. We should have made it a 13."

"We didn't finish these four stories, we’ll just carry them over to the next sprint."

"It's done, it just has to be tested. Let's make a new story just for that and mark this one done."

I hear these and similar statements all the time. Estimating, under normal circumstances, is hard. Then factor in what to do when your estimates were “wrong” and it gets downright messy. These statements are the most common reasons and scenarios I see when people ask about re-estimating work. 

So How Do You Re-Estimate Unfinished Work?

Short answer: I don't.

I never re-estimate work that is not completed. It didn’t meet the Definition of Done and it goes back to the product backlog where it can be considered for the next sprint.

The estimate doesn’t change because we started it or it’s harder than we thought, and we don’t get any credit for work that isn’t “Done.”

As a recovering project manager, I really love the simplicity of the Definition of Done (the quality measures required for the product). Like binary is just a series of 1s and 0s, the Definition of Done has only two states, “Done” and “Not Done.”

At the end of the sprint we look at each product backlog item and ask, "Has this met the Definition of Done?" If the answer is yes, it goes to the sprint review. If the answer is no, then it goes back to the product backlog. 

"Not Done" is also very precise — the product backlog item is not usable and therefore generates no value. It goes back to the product backlog and I treat it as if no work has been done. It’s in the product backlog and you treat it like any other item in the backlog. It just has the benefit of more “refinement.”

Why Don’t You Re-Estimate?

It's a fair question. There are a number of reasons for treating "Not Done" just like any other product backlog item. 

Must be usable: The first reason comes straight from the Scrum Guide. "In order to provide value, the Increment must be usable." I don't split a story just to get partial credit. If I could have split it into smaller work and still had it be usable, I should have already done that in refinement. We're focused on outcomes (value), not on output (work completed).

Code rots: I learned this from a wise developer years ago. Even in environments where "production" only changes every six months, the code base can change a lot in even a week's time. When work started on the new login interface, the environments were in X state. At the end of the sprint, the environments were in Y state and when we finally finished the login interface, two sprints later, the environments were in Z state. I've seen work that met the Definition of Done in the previous sprint that crashed the build system because it wasn’t deployed until four weeks later. "It just needs to be tested," is probably up there with "what could go wrong?" in statements that precede disaster.

Don't cut corners: This one is closely related to code rotting. If work isn’t completed in the sprint, I don't pick up in the next sprint like nothing has changed. I take all the tasks and bring them back to To Do. When I take up the work again, I validate all the work again. Not only has the "code rotted," you might have learned something new, have a fresh approach, someone else doing the work. By going back to the beginning, you’re ensuring nothing has been missed and quality remains high.

It all evens out: This comes into play both with work that is "almost done" and work that is "wow, that's a lot bigger than we thought it was.” You are going to get work that carried over from a previous sprint and was one point of effort to finish, and you’re also going to get work that ended up being three times as much work as estimated, and in the long run it all evens out. The law of large numbers basically tells us that the number of over-estimated will even out with the number of underestimated items over time.

Related Article: It’s Not a Target; It’s a Forecast

Just Don't Do It

If it didn't get done in the sprint, take it as an opportunity to look at the work all over again. Start with the acceptance criteria. Is it too broad? Can it be answered in a yes/no question? Look beyond this backlog item at the larger picture. Is the team taking on too much work, was this item dependent on another item, is there a challenge with the Definition of Done? 

Finally, take an opportunity to ask the question, “should we still be doing this work?” Every sprint is an opportunity to inspect and adapt. Part of that is looking at everything in the product backlog and asking, “does this still support the product goal?”

--

Want to stay informed on the latest scrum and agile stories? Please subscribe to stay updated.