Why we don’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)?
Want to drive efficiency and predictability in your organization?
Our organizational assessments give you the plan to grow these capabilities and accelerate your journey to real, impactful outcomes.
3 Responses to “Why we don’t re-estimate story points”
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?
In the case of what Carlos is speaking about I think that re-estimating is core of having clear and updated Backlog. I described this approach at: https://encrypted.pl/re-estimate-or-not/
rhetorical question: does it really matter?
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.