Should You Re-Estimate Story Points

Do you retroactively update your estimated time of arrival after you’ve arrived? No? Then why would you re-estimate story points?

Story Points are Estimates

The key to whether the team should re-estimate story points lies in a deep understanding of velocity and story points.

If velociy is the number of story points completed in a Sprint, what are story points?

Story points are an estimate of the size of a story. There are four main factors to consider with story estimation: complexity, uncertainty, risk, and effort.

There is a subtle nuance in this definition that I think many people either never realized or have forgotten. The primary takeaway from this definition is that story points are an estimate.

If story points are estimates, they must have an actual, right? Wrong.

Think about it, what is the accurate measure of risk? What about uncertainty? Even if you could somehow measure all of these aspects, how would you boil them down into a single number? Not just any number, mind you, a number on the Fibonacci scale.

Why Do We Measure Velocity

Let’s take this thought exercise a step further. Why do we measure velocity?

Is it to track the customer value delivered in the Sprint? No. Story points are not a measure of customer value. Story points are estimated by the team, with no customer involvement, and value isn’t a factor contributing to the ultimate guess.

Is it to give the team credit for all the work they completed in a Sprint? No, although this is a common misconception. The Development Team does a lot of work not represented by a Product Backlog Item. Meeting attendance, email management, and answering co-workers’ questions are just a few examples. Velocity is not a measure of productivity.

Is it so that we can use the information for planning? Bingo. Story points are only a planning tool that helps us forecast delivery and plan a reasonable amount of work for the next Sprint. The estimation process also helps ensure the team has a shared understanding of the work.

Now that we’re on the same page about story points and why we track velocity, let’s apply this information to answer the question: should you re-estimate story points?

Potential Re-Estimation Triggers

Two primary triggers will lead teams to change their estimates:

1. Newly Acquired Information

2. Incomplete Work

Newly Acquired Information

During story estimation, we make a lot of assumptions. When we later learn that those assumptions were incorrect, this new information might affect the story estimates.

Sticking with the initial metaphor, newly required information might change your estimated arrival time. Learning of a road closure or construction might warrant a call to inform someone that I’m running late.

Incomplete Work

The primary reason we desire to re-estimate stories is related to unfinished work. We believe we must have underestimated if we couldn’t complete the Sprint Backlog.

Incomplete work is similar to failing to reach an expected milestone by the predicted time while traveling. My mom lives about an hour away. If I leave my house at 2:00 and estimate arriving at Mom’s by 3:00, when I’ve not reached the midpoint by 2:30, one might suppose that my estimate was wrong.

Drawbacks of Re-Estimation

No ROI

If you are debating whether or not to update your estimates, ask yourself what benefit the activity will provide to the team. If you can’t answer this question, don’t spend the time to re-estimate.

Similarly, if you can obtain the same benefit more efficiently, opt for that solution instead of re-estimating stories. An example is teams who calculate actual story points at the end of a Sprint to improve future estimates. There are more straightforward, less nonsensical ways to achieve the intended results.

Back to this traveling metaphor, if I call my Mom to tell her I’ve not reached the midpoint I’d intended to by 2:30, there’s not a lot of value provided by that activity.

Velocity Inflation

Imagine you’re packing for a trip and suddenly realize you need some new socks. So you run out to the local Walmart and snag a bag. By some miracle, this bag of socks fits precisely into the limited remaining space of your suitcase. Because you’re not an animal, you want to wash these socks before you wear them. However, upon removing them from the dryer, you discover they’ve fluffed out to the point that you’ll never be able to get them back into their original package, and thus they no longer fit within the confines of your suitcase. Now you’re going to need a bigger suitcase, or you’ll need to take fewer socks on this trip.

Let’s relate this odd sock story to how we estimate user stories. Some teams will re-estimate stories as they pull them into Sprint Planning. You have a Product Backlog filled with estimated Product Backlog Items that total to a specific size, just like our original bag of socks had fixed dimensions. We had plans for these fixed dimensions just like the business makes plans based on the forecasted completion of the Product Backlog based on its current estimated size. We reduce our predictability by washing and fluffing our socks every iteration when we revisit our estimates. The socks never fit back into the suitcase, and the work never fits back into the forecasted release plan.

Imagine you have a Scrum Team that averages a velocity of 25. They have a Product Backlog with a total of 100 story points. We could forecast that this team would finish in 100/25 = 4 Sprints. When this plays out, however, they’re only pulling 20 points worth of work off the backlog in Sprint Planning, and those 20 points are re-estimated to be 25 points. In reality, this team will take 100/20 = 5 Sprints to finish the Product Backlog. This example is simplistic to prove a point. When these situations play out in real life, they make much more of a difference than a single Sprint.

When You Should Re-Estimate

1. New information affecting an entire class of user stories

2. Splitting Stories

New Information Affecting an Entire Class of User Stories

If we gain new knowledge that would affect the estimation of a group of product backlog items, then we should update the estimates for the entire class of stories. This effort should only include Backlog Items that we’ve not already finished.

Updating the entire class simultaneously avoids the velocity inflation abovementioned issue. We’re not slowing inflating the velocity each time we go through split planning. Instead, we’re making a one-time adjustment, which we can explain and justify to our stakeholders.

Splitting Stories

Anytime you split incomplete stories, you should re-estimate the resulting product backlog items, including divisions made at the end of a Sprint to reduce the carryover. It’s also worth noting that the estimates for your new stories are not required to add up to the original estimate of the first story. The goal here is to estimate based on the current information, not lock the team into their first impression.

When You Shouldn’t Re-Estimate

1. Indivisible unfinished work

2. Retroactive estimation

Indivisible Unfinished Work

Undone stories that the team cannot split shouldn’t be re-estimated. Instead, put the product backlog item back into the Product Backlog, and from there, the Product Owner can select it for a future Sprint.

It may feel like cheating to count a partially done story as eight-story points when you know the team has already completed a good chunk of the work. It may seem like velocity would be misleading, but tracking the data this way gives us more insight, not less.

Imagine a team with an average velocity of twenty points that planned twenty points for their seventh Sprint but could not finish one eight-point story. Their velocity for the seventh Sprint would be twelve points. In the eighth Sprint, they plan for and achieve twenty-eight points because they know very little work is remaining on the carryover story. Their average velocity remains unchanged (20+12 + 28)/3 = 20.

Some teams believe they should re-estimate the eight-point story when selected for the next Sprint since the remaining work is less. In the previous scenario, if the team had reduced the eight-point estimate to three points, their velocity for the second Sprint (assuming they finished all planned work) would only be (20 + 12 + 23) / 3 = ~18. Also, their velocity chart would show less volatility (the difference between twelve and twenty-eight is more significant than twelve and twenty-three).

The first method is a more accurate picture of what the team can and has achieved. It would be more accurate for this team to use the average velocity of twenty for Sprint Planning. Also, we want the volatility represented in the velocity chart because it can indicate a planning issue. We could not complete that eight-point story in the first Sprint, and we should talk about why and see if we can make any improvement to prevent that.

An average velocity of three sprints or more is a better indicator of what a team might be able to achieve than just their most recent velocity. The tendency to worry that one Sprint or the other is over/underinflated doesn’t matter because it will average out. Averaging reduces the effect of the volatility on Sprint Planning and allows velocity to represent done work - work that can provide value to the user.

Retroactive Estimation

I’ve read about a phenomenon where teams go through a process to determine ‘actual’ story points at the end of the Sprint. They compare actuals to the original estimates to glean insights from variances to improve their estimation capabilities.

Given the four factors that contribute to sizing stories, there is no proper way to calculate an actual story point. Efforts to do this are just another form of re-estimation.

The team could accomplish the same goal in the Retrospective by examining stories that took longer than the team expected, were unfinished, or had cycle times outside the norm. Also, this goal to improve estimates is a bit of a distraction, as the team should be more concerned with delivering customer value.

If I arrive at my Mom’s house at 3:30 and then inform her that I’m updating my estimated time of arrival to 3:30, she’ll give me a funny look. But if I tell her about some impediments I ran into along the way, she might impart some of her vast wisdom to help me avoid those impediments in the future.

Works Consulted

• Agile Estimating and Planning
• Is It Ever okay to Re-Point User Stories?
• To Re-estimate or not; that is the question
• The art of re-estimating undone work in Scrum
• Why we don’t re-estimate story points
• Lean Software Development: An Agile Toolkit: An Agile Toolkit
• Agile velocity is not a measure of productivity
• Stop Re-estimating Your Stories for Every Iteration

TLDR

When on a journey, your ETA is your estimated time of arrival. Story Points are also an estimate. Some circumstances warrant a change to the estimate. In other cases, it’s a waste of time to change your estimate; at worst, it obfuscates transparency.

Re-estimate when you know information that changes un-started stories in the Product Backlog or when partially completed work can be split at the end of a Sprint. All other types of re-estimation serve no real purpose, provide no value, and are therefore waste.