When this matters
A developer discovers an undocumented integration, a design changes after refinement or a key assumption proves false. Holding on to the original number does not protect the plan. Re-estimation is useful when the change is material enough to alter capacity, cost or the delivery date.
A practical approach
- Record the original range, confidence level and assumptions. Without that baseline, the team cannot explain what changed.
- Separate new scope from new knowledge about the original scope. A new feature needs its own estimate; an overlooked dependency changes the existing one.
- Estimate the remaining work, not the entire task from zero. Include work already done separately so progress remains visible.
- Show the revised range, planning value and effect on dependent work. Agree who approves a change to scope or deadline.
Example
A ticket was estimated at 8–12 hours assuming the existing API exposes customer status. After four hours, the team finds that the field requires a new endpoint and access review. The remaining work is now estimated at 10–16 hours. Report four hours spent, the new remaining range and the decision needed on the endpoint; do not quietly replace the original 8–12.
Make the next decision
Re-estimate at a meaningful discovery point, not after every small interruption. If confidence is low, time-box a short investigation and set a date for the next review. The original estimate remains useful as a record of what the team knew. Use the tool to produce a revised range from the confirmed scope.