Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

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

Last post 05:41 pm April 13, 2022 by Ian Mitchell
6 replies
02:58 pm April 13, 2022

Hello community,

Story points are based on the level of effort and should not convey the man hours it takes to accomplish them. Let's suppose that mid-sprint, the scope is much larger than the team had previously anticipated. The scope is larger because of a technical functionality being uncovered while the dev team works through a story. The level of effort from what they previously considered is  higher. My current team is changing the story points in the sprint backlog for those types of story. What is the reason that you should not change story points of stories in the sprint backlog?

03:11 pm April 13, 2022

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?

04:20 pm April 13, 2022

@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. 

04:27 pm April 13, 2022

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.

05:05 pm April 13, 2022

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

ato judge tentatively or approximately the value, worth, or significance of

bto determine roughly the size, extent, or nature of

cto 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.

05:22 pm April 13, 2022

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.

05:41 pm April 13, 2022

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.