We started doing point estimates 20 years ago in response to conditions of software projects in the late 90s. Arguably those conditions haven’t existed for many years. And like continuing to use crutches longer than needed to recover from an injury, continuing to use point estimates creates new weaknesses and obscures approaches to estimation that could make us even stronger and healthier.

Why We Use Point Estimates

Point estimates serve two critical purposes: they provide a means for software developers to deal with uncertainty, and they firewall a software team from uninformed deadlines dictated from outside the group of people entrusted to do the actual software work.

Dealing With Dictated Estimates

The firewalling aspect of point estimates works by creating a unit of measure for software estimates that is completely incompatible with the standard units of measure used in every other aspect of the business: time and money.

Without a standard unit of measure to express expectations, software developers effectively disrupted the lines of communication that carried the most unrealistic, ill-conceived, and uninformed work estimate dictates.

By adopting units of measure like story points and t-shirt sizes that aren’t directly convertible to time and money, budget and schedule controllers and software workers no longer spoke the same language as the rest of the business.

To a great extent, the adoption of incompatible units of measure took some of the more unreasonable heat off of software teams and gave them a bit of a reprieve to repair some of the historical damage done by the more harmful aspects of the prescriptive methods of the 90s.

Dealing With Uncertainty

Point estimates’ ability to encode uncertainty into the estimates remains an essential benefit of point estimation.

Higher values in point estimation systems, whether using the Fibonacci scale or the t-shirt size scale, convey greater uncertainty.

For example, an estimate of 1 point inherently has much higher assurance than an estimate of 13 points, and an estimate of 13 points has much higher assurance than an estimate of 40.

An estimate of 1 point conveys certainty because the task is small, has fewer factors to consider, and therefore is much easier to predict. An estimate of 20 conveys a scale of work that leaves a lot of room for the unforeseen. Estimates made at the upper end of the scale are effectively conveying guesswork.

The same can be said of the t-shirt scale. An estimate of Small has higher assurance than an estimate of Extra Large.

Communicating uncertainty to project stakeholders and principals is critical feedback from the people doing the work to the people requesting that the work be done (not to mention having authority over budget).

Hindering Communication with Point Estimates

In the levels of the organization immediately above the software development team, everybody deals with business-standard units of measure: time and money.

When software teams use points for estimation and progress measurement, they force everybody else to do the translation.

That’s not the best basis for a cooperative relationship. It risks eroding the credibility of software developers.

Developers also, ironically, perform the same mental gymnastics when using story points and t-shirt sizes, converting them implicitly into time. Sprints and iterations are measured in time, while work is measured in points. We inevitably retrofit our point estimates into the fixed time box allocated by our chosen iteration length to check whether we’ve done enough estimating for the sprint or iteration.

The Solution: Just Estimate in Time (But Use Ranges of Time)

Instead of estimating in proxy tokens like points, we can just do the estimate in units of time.

One caveat: time estimates should be given in a range rather than a single data point.

The purpose of estimating in time ranges is to preserve the level of uncertainty inherent in an estimate. You’re still required to convey uncertainty to stakeholders and to team mates. And you still have an inalienable right to be truthful about the uncertainty of any work item, and to not be pressured into giving a false estimate.

Examples of Time Range Estimates

If a 3-point work item implicitly equates to 3 days, you could then just give the estimate as 3 days.

But provide 2 data points: an optimistic estimate and a pessimistic estimate.

For example, that 3-point work item might be 2 1/2 days under ideal conditions, and may be up to 5 days if that code that needs to be changed is affected by that coupling that keeps us from making changes in that part of the system.

The estimate is:

optimistic | pessimistic
------------------------
   2 1/2   |    6

The optimistic estimate represents a best-case scenario estimate. The pessimistic estimate represents a contingency for potential setbacks that we suspect are within the realm of possibility.

A Single Number Time Estimate Is a Promise Rather than an Estimate

Unless you’re absolutely, positively certain of your estimate, don’t provide it using a single number (aka: a single-point estimate).

You’re absolutely within your rights to provide a single-number estimate, but you’d better not miss the target.

Providing an estimate without a range is a promise, not an estimate. It conveys that you’re so certain of the estimate that you don’t need to convey any uncertainty at all.

There are times when a single-pointed estimate is appropriate. But just make sure that when you give a single-pointed estimate that you’re comfortable with the repercussions of not fulfilling that promise.

Don’t make a promise you can’t keep. Especially, don’t unintentionally give a promise when you meant to give an estimate.

Encoding Uncertainty in Time Range Estimates

The broader the range of the estimate, the more uncertainty that is expressed.

For example, an estimate of between a 1/2 day and 1 day has a good deal of certainty. But an estimate of between 1 day and 10 days expresses the potential for quite a good number of uncontrolled circumstances that can result in a 1-day work item needing to take two work weeks.

It’s entirely legitimate to submit an estimate for a work item that is between 0 days and an infinite number of days. Such an estimate simply says, “I just don’t know”, or “I don’t know yet”.

As time goes on and uncertainty is turned into more certainty with the emergence of new knowledge and learning, the estimates are refined to reflect the greater certainty that knowledge provides.

Decoupling Certainty from Size

Range estimates decouple of the estimated size of a work item from the certainty (or uncertainty) of the work item.

Big work items don’t necessarily have to convey uncertainty as often becomes the way when using point estimate schemes.

For example, an estimate of between 20 days and 21 days has a lot of certainty. But it still remains a 20-day estimate for what is inevitably a significant piece of work. But an estimate of between 20 days and 40 days conveys a good deal of uncertainty, as well as conveying an item of significant size.

When Story Points and T-Shirt Sizes Are Still Useful

At the outset of a project (or in the face of any new knowledge and emerging understanding) when there is very little clarity in what is to be built, story points and t-shirts can be a useful placeholder for more precise estimation.

When there isn’t yet clarity of what is to be built, time range estimates can convey a level of specificity that falsely conveys more understanding than we actually have. We should never communicate with more specificity or certainty than we’re in possession of. Story point and t-shirt size estimates are a useful tool to keep us from implying that we’re in command of things that are still just out of reach.

We can fall back to loose estimates in story points or t-shirt sizes when we lack clarity, but it’s understood that these placeholder estimates will be replaced with more specific time range estimate when we get the clarity that we need.

More Formal Techniques

There are a handful of more formal techniques based on range estimates.

For example, you can derive probabilities from the ranges. Or you can add a best-guess estimate to the optimistic/pessimistic range and triangulate and confidence intervals.

Using statistical methods to derive probabilities and confidence intervals can lead to the mistake of conveying more specificity and certainty than the underlying calculations can deliver. A detailed discussion of such approaches is beyond the scope of this article. There is an incredible amount of documentation available on such techniques readily available to anyone who wants to dig deeper.

You can go a long way with two-pointed optimistic/pessimistic before engaging any of the more esoteric extensions of the technique.

A Note on Agile Project Management Tools

It’s likely that your organization has adopted an Agile project management tool that has become indistinguishable from your team’s process. It’s also likely that your tool of choice doesn’t have provisions for anything but single-pointed story point and t-shirt size estimates, and doesn’t allow you to record range estimates.

The limitations of your tools should never be allowed to limit the improvement and advancement of the process itself. If your tool doesn’t allow the recording of range estimates, then don’t use that tool for estimates.

It’s important to note that your organization, at some point in its recent history, made the transition to the tooling you’re using now. In the mid 2000s, we all made transitions to Agile tools. We have all already demonstrated an ability to make such transitions. Not to downplay the effort, but transitions to new tools is far from insurmountable.

As a concrete suggestion, you can easily keep work item range estimates in a Google Spreadsheet that your team can share. You might balk at the notion of using multiple tools, but such is a characteristic of transitions. Having the estimate data in a spreadsheet also allow you to interactively explore what-if scenarios and experiment with some of the probabilistic techniques.

Tools always lag behind techniques. Which, by the way, is why Agile pioneers and leaders have always cautioned against allowing any tool to become so entagled with a team’s development process that it halts or complicates its improvement process.

Conclusion

Point estimation was a specific countermeasure for a specific set of conditions, conditions that largely aren’t as much of a problem anymore. It’s not that point estimates aren’t useful, but their utility is confined to circumstances and conditions that are increasingly rare 20 years into Agile.

Adopting time range estimates not only frees you from rituals and ceremonies that were more useful 20 years ago, but it will also bring you into greater alignment with the rest of the business you operate within. And doing that will increase the business’s trust in you and increase your credibility.

Trust and credibility are assets that you can leverage toward making even more advancements and improvements going forward.