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)?

What’s Your Organizational Agility Score?

In less than an hour, you’ll get valuable insights into your organization so you can improve team performance and achieve your business goals faster.