When to Re-Estimate Mid-Sprint

Sprint estimates are made with imperfect information. When new information arrives mid-sprint - a discovered dependency, a scope clarification, a technical constraint - the question is: do you re-estimate, or just absorb it?

When re-estimation makes sense

Scope has materially changed. If the Product Owner added requirements to a story after sprint planning, the original estimate no longer applies. Re-estimate the story, and if the new estimate pushes the sprint over capacity, remove something else. This keeps the sprint commitment honest.

A technical discovery changed the approach. Finding out mid-sprint that the original approach won't work, and pivoting to a different one, often changes the size significantly. Record the new estimate for retrospective purposes - it helps calibrate future similar stories.

When re-estimation is unnecessary churn

The work is taking longer than estimated, but scope hasn't changed. Don't re-estimate just because a story is going slower than expected. It's tempting to update the estimate upward to make the sprint look on track, but that's data manipulation, not process improvement.

Small discoveries that don't change the overall picture. Normal implementation complexity that was already implicitly part of the estimate doesn't need to be re-litigated.

How to handle re-estimation without derailing the sprint

Keep it fast: a quick sync with the relevant developer and the facilitator to confirm the new scope, a new estimate, and a decision about what to remove from the sprint if needed. This shouldn't require a full re-planning session.

Recording what happened

Note re-estimates in your task tracker with a reason. Over time, the pattern of what triggers re-estimation tells you where your initial estimation process is weakest.

Re-estimation is a correction mechanism, not a failure. Use it when scope changes, not when progress is slower than expected.