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.
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.
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.
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.
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.
Visit truestimates.pressbin.com to see a sample sprint visualized using TRU Estimates.
And if you'd like to try planning your own team's next sprint using TRU Estimates, I've created a free tool for sprint planning using TRU Estimates.
Shaun Gallagher is the author of three popular science books and one silly statistics book:
He's also a software engineering manager and lives in northern Delaware with his wife and children.
Visit his portfolio site for more about his books and his programming projects.
The views expressed on this blog are his own and do not necessarily represent the views of his publishers or employer.
Adapted from a 2020 study, this web experiment tests a cognitive quirk that contributes to dogmatic worldviews.
This student guide explores three economic systems (capitalism, socialism, and distributism) and explains how distributism is different from the other two.
What if making money is not one of your top goals? And what if you happen to stumble into a high-paying career nonetheless?
How to build up and encourage code authors during the review process
A poem about all the rules you can break and the one rule you can't.