Why we don’t re-estimate story points

By Agile Velocity | Mar 26, 2018 |  Article,  Product Owner,  ScrumMaster

You can't re-throw a dart just like you shouldn't re-estimate story points


To estimate or not? To re-estimate or not? This short article will tackle the second question. We’ll weigh in on #EstimateGate in a later blog post.

Most teams are tempted to re-estimate stories once the Sprint has begun; as teams put fingers to keyboard, it is natural that they learn more about what is actually involved. Hence, the temptation to re-estimate story points because (and this is just a guess based on our coaching experience), they want to be right, or accurate.

Precise vs. Accurate vs. Consistent

A quick review of terms:

Accurate – In terms of measurement, accurate is synonymous with exact. It is not 11:00, it is 11:06am. A common way to describe accuracy is hitting a target on the bullseye.

Precise – You need a few more throws at the dart board to be precise as this adjective refers to the closeness of several things in relation to one another. A group of darts in the same area means the thrower is precise. You can be accurate and precise if you have a cluster of darts at or near the bullseye. However you were accurate and imprecise if you have darts all over the place and only hit the bullseye once.

Consistent – Like precision, you need several measurements to use this term. Consistency describes the measurement of a group of items that are the same. If each apple in a bucket of apples weighs around 5oz, then a farmer can describe that weight to be consistent with apples.

When teams have been working together for a long time, their estimates become consistent. If a team has built one travel app, then they can rely on their past experience to estimate their next travel app. If they have built 10 travel apps as a team, then their estimates for travel apps should be consistent. Using this past information, it is likely that their estimate for the 11th app will be accurate as well as precise or consistent.

Instead of shooting for accuracy, teams should aim to be precise or consistent.

Fight the temptation to re-estimate

Some teams believe that velocity is a measure of how much they got done. With this mindset, velocity proves their work and effort. Therefore, it is tempting to change the estimate if more work (and bigger size) was needed to finish the story.

However, velocity is a measurement used to determine what teams can get done in the FUTURE.

Teams never have perfect information when they are estimating and planning upcoming work.

If a story was estimated to be an 8 and it ended up being way easier (let’s say in the 2 range), don’t change it. The past should stay in the past. Anomalies are concerning, only if it happens a lot. We are looking for consistency in story point estimation not accuracy. Also important to note that it’s important to estimate the whole backlog with same fidelity (understanding) of knowledge.

Re-estimation of story points…

  • Does NOT improve accuracy
  • Decreases consistency in their ability to forecast

So what do you do if the story ends up bigger?

If for some reason the scope changed and the story is bigger, then the Product Owner should create another story capturing the NEW work. This new story should then be estimated and prioritized within the backlog.

If sizing is consistently off, during the retrospective, dig deeper with the following questions:

  • Why are we only identifying the size issue at the end of the Sprint?
  • What caused the story to be a different size?
  • Was it a scope issue or a time issue?
  • Did we do something this Sprint that made work easier (and therefore smaller) or harder (and therefore bigger)?

If you have more questions about processes like sizing story points or backlog refinement can help you create key business capabilities, consider an Agile assessment. Agile assessments help organizations understand how Agile is helping them get results like predictability, engagement, and innovation. Watch the video to gain 6 benefits of an Agile assessment and contact us for questions. 

7 Responses to “Why we don’t re-estimate story points”

  1. In this article you are talking about the re-estimation when the sprint already started. But what happens if the team didn’t finish a story during the sprint. Let’s say that the team accomplish a 90% of the tasks to finish the user story. Should the team re-estimate the story with the remaining tasks or should it keep the original points?

      • Matthew Davison

        rhetorical question: does it really matter?
        answer: no

        With their new knowledge, a team can merely estimate better next time. It all washes out in the average velocity over time, anyway…
        Re-estimating doesn’t serve the customer and it bespeaks a team that is looking for credit. Velocity is not a speed limit, it is an advisory tool – i.e. a squad should be able to say when their sprint is full fairly accurately without knowing their velocity. They’re not clueless idiots.

        Save time, remove waste, don’t re-estimate.

  2. Bryan Woodward

    While I generally agree with this, there are some obvious progressive elaboration aspects of this that may need to be addressed. Since technically Sprint Planning is the first event of the Sprint and its generally the first opportunity to get into the weeds the actual work, it feels like you may want to update your estimate after Sprint Planning. This is currently what our team does.

    The second case I could foresee is if through development you uncover a necessary change that is needed to complete the sprint goal, it may make sense to update those story points to account for the unforeseen work. I only advocate this in the case that you “plan” out that additional work. I.E. Turns out the data file needs to be scrubbed and it will take us 4 extra points to perform the scrubbing of the data. Because you still haven’t completed that work, I would advocate that updating the points would make sense.

    Basically, I would advocate updating story points up to the point that development starts on a given “planned” set of work.

  3. Andy Cleff

    Bryan – It depends on the problem the team is trying to solve…

    What do they hope to gain by re-estimating individual stories (i.e., the value)?
    What is the cost of re-estimating?
    What other ways could the team address the problem? (e.g., more time refining, iterating on DoR, or gasp – #NoEstimates, etc.)

  4. Pradipta Ghosh

    I need a suggestion in my case. In my project, a story was initially estimated at 8 points and it finally took way longer than because of the development team’s technical deficiency in that particular programming language. Should we break the story into smaller chunks and estimate each chunk separately? I personally disagree cause I feel that will be data manipulation.
    Could someone suggest?

  5. Andy Cleff

    The goal of every “failure” should be learning. What does the team hope to learn in this case?

    Examples might be:
    We need to revisit our definition of ready
    We need to do spike stories when we are working with a new (to the team) technology
    We need to split stories bigger than “X” down to minimize risk
    We need to pair program more
    We need to inspect our daily stand up to make sure issues like this come up sooner
    We need to…..

    Splitting this one story now feels to me like an anti-pattern….
    Which raises the issue: why would the team want to manipulate data? Are there perverse incentives driving that?

    Re: story splitting for the next backlog refinement session – see the wonderful resource here:

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back