Imagine a situation when you are finishing a Sprint and not every issue in the Sprint is done. Question here is what should you do? Should you re-estimate the spillowers or not? I think that you should always re-estimate and I am going to prove why.
Background, so why are we estimating?
We are estimating stories to make better predictions about when we will be able to deliver features. So re-estimating or not should best help us with forecasting the future and that will be main criteria I used.
Why you should consider re-estimate the spillovers?
Total size of a Product Backlog should be updated
Spillover might be done in the next Sprint and might not. Technically before moving them to the next Sprint we should put them in the Product Backlog. The problem with that is if we didn’t re-estimate them we will have the wrong prediction about how big our Product Backlog is. As Ian Mitchell points out in this thread we should expect that the total size of a Product Backlog will change.
Use oportunity for inspection and adaptation
When there is a spillover then we failed with the planning or with the execution. Either way, nobody questions that we should take a look at our process during the retrospective and seek for causes. The same motive stands for bringing up spillovers to the refinement. And there is no point in refining stories and not changing estimates. It will be anything but transparent.
Motivate the team to deliver on deadline
With the rare occurrence of constant spillovers and constant moving them to the next sprints we will actually learn the team that this is fine. All the story points will be counted later and everything is fine. I think that this is just sweeping agility under the rug.
What are the arguments for not doing re-estimate?
Velocity will averages
One of the major arguments for not re-estimating is quoting Mike Cohn from his post. He wrote that: “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”. I see that this approach just creates more questions:
- What if PBI won’t be completed in the next Sprint (what if it will spill over again)?
- What if the cause of spilling over is an unexpected impediment and currently PBI will be estimated much higher?
Such questions generate additional complexity, which is handlable but unnecessary.
Re-estimating will lead to inflation.
As we can read in Adrian Wible blogpost from his experience re-estimating almost always caused problems and delays. He provided the example of a team that was always re-estimating higher and never lower, so in his opinion estimates grow with he precision.
Although the story he described might be true I don’t think this is a valid point. Truth is when we face such an issue problem lays in teams’ pursue of delivering more story points.
Why do I re-estimate?
I am sure that both approaches have their followers. Their main pros and cons are described in this table.
| Re-estimating | Not re-estimating | |
| Can we measure team velocity? | ✔️ | ✔️ |
| Can we measure how much work remained? | ✔️ | ❌ |
| Is it transparent to someone from outside the team? | ✔️ | ❌ |
| Is it quicker? | ❌ | ✔️ |
I leave it for you to choose the approach that fits you best, but personally I always do at least these two things:
- Rename the story title to “Finishing started (…)”
- Re-estimate the spillovers.
The reason for that is I aim to do a little bit more, to stay transparent for anyone who would like to inspect our work.