Why should you not re-estimate story points when scope changes?

What is the reason that you should not change story points of stories in the sprint backlog?

Try looking at it the other way around. Why shouldn't the team have a clear view of the amount of work they now believe remains?

@Ian Mitchell, I think they should have a clear view on the amount of remaining work. But I just think that the more that a team works through flushing out ALL details, scope creep becomes apparent. 

Teams should not adjust story points mid-sprint because it obscures transparency into the decision-making around the original estimate, and reasons why the original estimate was way off.  It detracts from the team's ability to inspect, adapt, and potentially improve their estimation practices.



To use an analogy, I can be the greatest archer in the world if I were allowed to move the target to where I shot the arrow.

Story Points are estimates which are guesses.  This is the definition of "estimate" as a verb according to Merriam-Webster. 

a: to judge tentatively or approximately the value, worth, or significance of

b: to determine roughly the size, extent, or nature of

c: to produce a statement of the approximate cost of

In software development/project management, estimates are used to approximate a level of effort before work begins.  After work begins, estimates become unnecessary.  By changing your estimate after work is began, you are venturing to the realm of measuring.  

Measurements are used to quantify elements.  You measure the distance from 1 spot to another.  You measure the amount of ingredients put into a cake.  They are more precise than an estimate. 

If the situation is that more work than originally estimated is uncovered, re-estimating can be useful to determine if the body of work should be adapted.  However, you should not get into a habit of changing estimates to try and better represent the actual work.  That changes the estimate to a measurement.

For me, this comes down to the effort not being worthwhile.

Estimates are not a requirement in Scrum. An estimate may be an attribute of a Product Backlog Item that the team adds through the act of Product Backlog Refinement. If a team does choose to estimate Product Backlog Items, then I would assert that the best place to use those estimates is at the Sprint Planning event. The team could use estimates, along with their forecast capacity, to make sure that their Sprint Goal is something that is reasonably or likely to be achieved over the course of the Sprint. The team could also use estimates to determine if the Product Backlog Items selected for the Sprint Backlog represent a body of work that is likely to be achievable.

However, once the Sprint starts, the important thing is that the team strives toward achieving the Sprint Goal. If the work that is discovered mid-Sprint would put the Sprint Goal in jeopardy, I would recommend that the team begin to involve the Product Owner to understand what the best tradeoffs would be. However, as long as the Sprint Goal is not in jeopardy, the team should continue to work toward the Sprint Goal as their priority.

Stopping the work in the Sprint to re-estimate work opens up the potential for a lot of waste. Who is involved in the re-estimation? How long will it take? Will this become standard practice? Since the estimate is only valuable at the time of planning, there's little value in expending valuable time during the Sprint for re-estimation, when that time could be spend designing, building, and testing the product being created or refining upcoming work.

If the work remains undone at the end of the Sprint, it goes back on the Product Backlog. The team may have time to revisit and further refine the Product Backlog Item between Sprint Review and the next Sprint Planning session. Perhaps re-estimation is something that could be done then, if the team feels that it is valuable to spend some additional time refining that work before the next Sprint Planning to come to a clear understanding of size and scope of the work.

If estimates are vastly off from actuals and this is preventing the team from effectively planning their Sprints, then that is a good topic of conversation for the Sprint Retrospective. The team can look at their understanding of the product and its context along with their refinement and planning practices to figure out how to improve for the future.

I think they should have a clear view on the amount of remaining work. But I just think that the more that a team works through flushing out ALL details, scope creep becomes apparent. 

Zeno's paradox of Achilles and the tortoise: Both start off at the same moment, but the tortoise is given a head start and begins to move even further ahead. Achilles can run as fast as he likes but will never catch up with it, because he must first reach the point where the tortoise started, by which time the tortoise will have moved ahead again, even if only by a small amount. By the time Achilles gets there, the tortoise will have moved on yet further, etc.

Estimation, like Zeno's paradox, is a problem of continuum. This was addressed by Aristotle who recognized that the discrete segments of Achilles’ motion are only potentially there, and not actually there, since he never actualizes them by stopping. 

In other words, you may indeed have a problem with scope creep if you stop too often to estimate. Hence estimation ought to be done with economy -- do just enough to gain sight of the work needed to complete, but no more. The time would be better spent just getting on with things and doing the work.