TRU Estimates, a better alternative to story points

Those of you who practice Agile software development are likely familiar with the concept of story points.

But story points compress information about effort in an inherently confusing way.

I've developed a simple alternative, called TRU Estimates, that allow effort to be communicated in a way that clears up the confusion, leading to more accurate estimates and more clarity among stakeholders about what those estimates represent.

What are TRU Estimates, and why use them?

TRU stands for Time Range/Uncertainty. It's a better way of estimating effort.

You've likely heard that story points are not a measurement of time. Rather, they are a measurement of overall effort, which takes into account factors such as time, complexity, risk, and uncertainty.

But ultimately, stakeholders just want to know how much time things are going to take. Story points might not themselves represent time, but they are used to determine velocity, which is used to determine how much work the team can pull into a sprint with a defined length of time — so when you boil everything down, it's all about one thing: time.

Mathematically, we can think of story points as a measure of the central tendency of a multidimensional dataset. You might be familiar with common measurements of central tendency, such as mean, median, and mode. These reduce a large data series down to one representative number. But that reduction comes at a cost. Datasets with very different values can have the same mean, median, or mode.

The same holds true for story points. One story might have a high story points estimate because it is straightforward but will take a lot of time. Another story might have the same estimate because it is complex and there is increased uncertainty about how long it will take.

Being able to represent and visualize the various dimensions that together make up effort can reduce the confusion that often arises when story points are used to estimate effort. TRU Estimates reduce confusion for development teams and other stakeholders.

The measurements that matter

Forget about complexity and risk. They each reduce to a combination of time and uncertainty, which are the only two measurements that really matter.

Fortunately, time and uncertainty can be represented using as few as two numbers: the minimum and maximum of a range of possible values. (This assumes that our uncertainty estimates follow a normal distribution pattern, where the actual amount of time a story takes to complete is more likely to be close to the middle of the range than the periphery; adding a third number to represent skewness of the curve is possible, but probably overkill.)

This is how TRU Estimates represent effort — as a distribution curve over a time range.

Is this hard? Does it take longer than estimating in story points?

Using time ranges is no more difficult than using a single value to represent effort, and what you will likely find is that estimating takes even less time than when using story points.

Here's why.

When a developer is asked to estimate a story's level of effort, they must internally perform multiple estimates — all of which reduce down to time and uncertainty. They must then pick a single number that represents all of those estimates. Differences between story point estimates, which must be ironed out through further discussion to arrive at consensus, often arise from the fact that we are bad at performing this reduction in our heads in a consistent way.

Making multidimensional estimates more explicit, and eliminating the amount of mental gymnastics developers must perform, makes it easier to arrive at consensus quickly.

But how do I work with TRU Estimates?

When you work with story points, you add up how many points you completed per sprint over several sprints, and the average determines future velocity.

But how do you add time ranges that represent both time and uncertainty?

One way is to generate story points from these estimates in a methodical way, then use those to calculate velocity. This allows your team to estimate and visualize your sprint using TRU Estimates, but still have a straightforward, less error-prone way of calculating velocity.

For instance, in the sample sprint above, story points are generated using a consistent formula that takes into account both time and uncertainty. Having story points be the generated outcome of a TRU Estimate allows developers to make better estimates without needing to change anything about how they use or track story points.

Another way to work with TRU Estimates is to abandon story points entirely. Instead of identifying a story or sprint with a single number, representing story points, you can identify it with two numbers, representing a time range.