Re-Estimating a story's points midway through a timebox

Question

I have recently come across this situation:

• user stories are estimated using story points
• timebox planning session has taken place and everything is agreed on
• timebox (three weeks) is in week three
• team decides a story has been estimated too small but still thinks that they can get it done in the timebox

However, the team wants the original estimated story point value to be increased, say from 5 to 13 to reflect how much effort is now involved.

My own feeling is that the story points have been estimated as a best guess to aid with planning. Now that the timebox is under way, I think the team questions if the story can still be fully completed within the timebox. We should not re-estimate it. However, it may be useful to keep a note for future estimating or planning sessions for similar items.

The culture is that story points are used as justification of what team members contribute to the timebox, and therefore always get mapped to days:

• 3 = 1 day
• 5 = 2 days etc

Personally, I don't agree with this approach and re-estimating the story seems another symptom of this issue.

Normally, if the team has committed to delivering 100 points based on previous velocity and the client asked to add 8 points during the timebox we would say no as the velocity is 100, the timebox is fixed and we couldn't possibly add more.

Likewise, it should not then be OK for the team to effectively increase the velocity to 'fix' a perceived estimation problem.

I guess my question is: What would be recommended practice for re-estimating a story mid timebox and what are the pros and cons of the approach my team wants to take?

Note, I am not the project manager in this team.

Answer 1

TL;DR

Story estimates are estimates, not guarantees. They contribute to an overall average velocity range that is useful for capacity planning. They are not management targets, and changing story points within a Sprint tends to sweep process problems under the rug and artificially inflate/deflate a team's velocity.

An accepted axiom of agile planning is that story points are a measure of relative size (not time). The estimates are often wrong in the specific, but in the statistical aggregate they approach a "good enough" number for planning purposes and scheduling control.

Handling Inaccurate Estimates

We should not re-estimate it. However, it may be useful to keep a note for future estimating or planning sessions for similar items.

This is correct. The estimate developed in Sprint Planning is the estimate; it must not change within the Sprint.

Having said that, if a story has been mis-estimated, you have several choices:

1. Do the best you can with it; the story will then either be done or not done at the end of the Sprint.
2. If the story is essential to the Sprint Goal, coordinate with the Product Owner to see if the story's scope can be modified without negatively impacting the Sprint Goal.
3. If neither the Sprint Backlog nor the story scope can be changed without risking the Sprint Goal, then:
   • the team can swarm over the story at the expense of other (perhaps less critical) stories, or
   • the team can ask the Product Owner to call for an Early Sprint Termination and a return to Sprint Planning.

Regardless of how you deal with the issue, the mis-estimation (including assumptions, unexpected process issues, roadblocks, and so forth) should be grist for the mill at the next Sprint Retrospective. The point is not to lay blame for the incorrect estimate, but to understand the root cause and to continuously improve the estimation and planning process.