Relative Versus Absolute Estimates

Sep 14, 2012

A common question is “How should Product Backlog Items (PBIs) be estimated?”. Some will assert story points are the correct answer, some find comfort in using days & hours.

The correct answer is: scrum is silent on this question. “Scrum … does not define an estimation technique.” – Scrum Primer, p. 8

While I appreciate that people are more comfortable estimating using days & hours (“it’s the way we have always done it”), I believe absolute estimates mislead us and often force dysfunctional behavior. Relative estimation should be our preferred choice here. There is ample academic research (ref?) to support the well known problem that developers cannot estimate well. The causes are manifest: software is quite complex, we often make invalid assumptions, optimism often skews our views, we rarely have mechanisms to learn from our mistakes, etc, etc.

The further out in time we look, the poorer our estimates will be. This is why sprints are short, so we can detect and correct frequently.

Relative estimates play to human psychology. Even small children can size up two objects and decide one is twice (or three times) the size of the first, without knowing the slightest bit about absolute units of measurement. Story points leverage that bit of human insight and allow us to get the PBIs sized, relative to each other, in a way that is useful for release planning.

The beauty of relative estimates really becomes apparent during sprint planning. Based on a team’s velocity (average points completed over the past three sprints) the team picks PBIs that add up to about that amount of work. This is a self-correcting system! If a team does well/poorly, the velocity will trend up/down and the amount of work accepted into a sprint automatically adjusts. This also gives us the ability to predict the future with our release plan, based on empirical evidence of progress (working code). If we estimate PBIs in days & hours, the team will feel compelled to pull in as much work as there is time in the sprint, regardless of the team’s actual velocity. The pressure to over-commit is not at all subtle here, and should be avoided.

“Velocity is the way they naturally account for the difference between an ideal 8 hour workday and the hacked-up, interrupted, full-of-meetings, occasionally longer-lunch, day. Team velocity represents the team’s capacity with all the messy details of real work situations already accounted for.” (Erickson)

Since every team will normalize to their own reference unit (“how long is a piece of string?”), there is no way to compare two teams to each other. In other words, a team with a velocity of 25 cannot be compared to a team with a velocity of 12. We are interested in predictability, and eventually helping the team walk their velocity upward, but one should be careful that velocity is a terrible metric and is trivially gamed. If you want the truth (transparency) you have to be prepared to accept an answer without causing a negative feedback loop.

Avoid absolute estimates for Product Backlog Items and learn to manage a release plan using the velocity of your team.