To Re-estimate or not; that is the question
Should a team that is estimating in story points ever re-estimate? This is a question I'm commonly asked and would like to address here. Most people have a natural feeling that re-estimating is somehow wrong but they can't quite say why. I'll encourage those individuals to stick to their hunches, and hopefully I can provide of the reasoning that supports your natural inclination that most re-estimating is wrong. Philosophers talk about two types of knowledge.
The first is *a priori* knowledge, which is knowledge before you experience something. Let's call this* knowledge-before-the-fact*. This is the type of knowledge we have when we estimate something. Before estimating development of the new search screen I think it's about 8 story points, because it seems to be about the same total effort as some other 8 point story. The other type of knowledge is called *a posteriori *knowledge by the philosophers. This is knowledge *after the fact*. When we estimate it is important that we not mix *knowledge-before-the-fact* with *knowledge-after-the-fact*.
Suppose you are looking at a Scrum product backlog that has just been estimated with none of the work started. Each of those estimates was given before-the-fact (a priori). Now suppose you are looking at the same project a few months later. You've got a list of completed work, some of the items on that list still show their original, before-the-fact estimates but some have been re-estimated with after-the-fact estimates. The product backlog is similarly mixed: mostly the initial, before-the-fact estimates but some estimates that have been revised after-the-fact because of what was learned by developing previous user stories off the backlog. Having both before-the-fact and after-the-fact estimates on your product backlog and list of finished work can cause a lot of confusion for the project. When all estimates are given in before-the-fact numbers we can reason about them and compare them.
Suppose the team is estimating a new item and want to say its equivalent to 20 story points because it's similar to another item that has been estimated at 20 story points. That logic makes sense if the original item has not been re-estimated. If the old item was given an estimate of 10 before the fact and re-estimated to 20 after the fact then it is harder to know if the new item should get a 10 or a 20. With the re-estimation having occurred we're in the position of saying "Before I start this one I think it's a 20 because the other one felt like a 20 after I did it." That's weaker than "Before I do either of these they seem the same size."
So, does this mean you should never re-estimate? Absolutely not. There are times when you want to re-estimate. Generally re-estimating is useful when you completely blew it on the original estimate and can see that the mistake was a rare occurrence. (That is, if every estimate is systematically off by half I wouldn't re-estimate.)
Second, you should re-estimate when there has been a change in relative size. For example, the team has discovered that learning AJAX will be about half as hard as they thought. We'd want to fix that because the new knowledge tells us that our relative estimates are off-kilter for the AJAX-heavy stories.
When Should We Estimate the Product Backlog
FeaturedEstimate backlog items at the right time and level of detail.
What Are Agile Story Points?
FeaturedUnderstand what story points measure and why they are often misunderstood.
A Second Way to Prevent Estimate Inflation
FeaturedLearn one more practical technique for preventing estimate inflation and keeping your team's story point estimates useful over time. Go beyond the blog post - find out one more way to prevent estimate inflation.
Story Points Estimate Effort Not Just Complexity
Clarify why story points estimate effort, not just technical complexity.
Four Reasons Agile Teams Estimate Product Backlog Items
Estimating product backlog items provides benefits beyond predicting when a project will be finished.
Product Backlog
The product backlog is the Scrum Team’s ordered list of possible future work for the product. It includes the work the Product Owner may ask the Scrum Team to build, fix, research, improve, or learn about next.
Story Points
Story points help agile teams estimate product backlog items by comparing one item with another. They are useful because teams rarely need perfect predictions.
Estimating
Build practical agile estimating skills with story points, planning poker, triangulation, velocity, and techniques for making useful forecasts without chasing false precision.
7 Ways to Get the Best Estimates of Story Size
Agile teams often struggle to estimate product backlog items. Here are 7 ways to make solid improvements.
The Five Possible Estimates and Which One Your Team Should Use
Unless team members have discussed it, they are almost certainly providing different types of estimates.
Should You Use Zero-Point Estimates on Your Product Backlog?
Understand when a zero-point estimate is useful and when it hides real work.
Estimating & Planning
Improve estimates, forecasts, release planning, and conversations about scope, timing, and risk.
Don’t Equate Story Points to Hours
Story points are about time, specifically effort. But that does not mean you should say, “One story point = eight hours.
Plan Visualizer
The Plan Visualizer is a free agile forecasting tool for testing whether a target scope can be completed by a target deadline. It plots the plan against a low and high velocity estimate so teams and stakeholders can…
Velocity Range Calculator
Use this to calculate a velocity range from historical sprint data and support milestone forecasting.
Accurate Agile Planning
Help teams create credible forecasts, plan under uncertainty, and make better decisions about scope, timing, risk, and tradeoffs.