Software Estimation that Works, Part 1: Ranges. Confidence and Risk

Estimates Cannot Be Precise

“How long will that take?” No other question stops a tech team dead in it’s tracks.

Without exaggeration, it is like asking a new parent, “So how much do you think it will cost to send you kid to college?” If you are that parent and paid your own way, or maybe even paid for a previous kid; despite that experience, you know that you are hazarding a guess. It might be an informed guess, but it still fraught with uncertainty. Worse yet, the question implies a bunch of new worries heading your way. They are not asking some 3rd party financial advisor. They are asking YOU, the person who is expected to be able to pay this hypothetical bill once it is less hypothetical.

When you ask a tech team to estimate a date, they are just as aware that 1) they are hazarding a guess and 2) they will be expected to do the work to make that guess a reality.

People hate to be put on the spot, so there is some jujitsu in this method of estimation. Instead of asking for specific estimate, ask for a range. Giving people the wiggle room gets them out of the “I have to be exact, because I am going to be held to it” mentality. Be aware that phrases like “how long” or “when do you think you can be done” are being heard as demands for commitments.

Asking estimators for a likely range instead of a date has several benefits beyond putting your estimators at ease:

* gets everyone beyond the illusion of precise estimates
* gives you an idea of the team’s confidence in their estimates
* shows you where the risks are in the work ahead

High, Medium, Low

My favorite range estimation method is called High/Medium/Low or the 1-1-4 method. Ask your estimators to give you a range in three numbers:
* a low end estimate, if everything goes right
* a most likely estimate, if things go as you expect
* a high end estimate, if things go badly.

If you estimate your range in these three parts, you are thinking about the task from an optimistic, pessimistic, and a realistic point of view. Most teams sway one way or the other: either delivering overly optimistic or pessimistic estimates. Consciously trying each mode exposes more data. In the optimistic mode the team is describing what the work would look like if everything went right. In the pessimistic mode, they are forced to think through possible risks, complications, or just time sucks. Using experience to see how these two extremes balance out, the team usually ends on a more informed realistic estimate than if they just did a single point.

As a person gathering this data, you are now exposed to more raw data. You are not getting estimates that may be padding, or may be waiting for your padding. You have a High, Median, and Low to work with.

Working with Ranges

If you assume that low, median, and high end fall on some sort of bell curve, you combine them with:

This is where the name 1-1-4 comes from. You multiply the MEDIAN, or the most likely scenario by 4, and add in the best and worst case. Then you divide the total by 6. This gives you a weighted average that assumes that likely estimates are 4 times more likely than the worst or best cases. This method allows you to:

* factor in large deviations caused by worst case scenarios
* spot if your estimators best cases and most likely are often the same (too optimistic)

Example

Task: Integrate with a 3rd party data service.

LOW 1d The system probably uses JSON or another well known format. It could be fetched by a simple URL request and parsed with our existing systems
MEDIAN 3d The system probably uses a well known format, but their will probably need to be some tweaks to the serialization library. If they are not using standard HTTP retry and error codes, we might have to add some custom handlers and additional unit tests.
HIGH 15d They are using a custom serialization, so we will have to implement our own parser/serializers. If they did that, we probably also have odd-ball network issues. They could be using SSH security and require some sort of certificate setup.

AVERAGE = (4*MEDIAN + LOW + HIGH)/6

AVERAGE = (4*3 + 1 + 15)/6 = 4.7d

AVERAGE rounded to days: 5 days

Confidence

In the above example, there is a wide swing between the HIGH(15d), MEDIAN(3d), and LOW(1d). When you are looking at a set of estimates that you are using to build up a project schedule, you want to look at the confidence your team has in their estimates and the risks behind these estimates.

Confidence is how wide is the range. The more sure a team is of an estimate, the narrower the range.

CONFIDENCE = MEDIAN/AVERAGE

CONFIDENCE = 3/5 = 60%

The closer the confidence percentage is to 100%, then there narrower the range. If you are looking through a set of estimates, you want to examine the ones with low confidence percentages. The team might not be able to give a high confident estimates for lots of reasons. Diving into open questions might help gain confidence and narrow the gap.

Do the requirements need clarification? Does some technology need to be tested or researched? Are you dealing with a un-tested or unreliable vendor? Asking these questions might help you add additional data to the estimate to increase confidence. Or, it could be early detection of a problem with the plan.

Risk

If you have two estimates with low confidence percentages, they might not warrant the same attention:

TASK LOW MEDIAN HIGH AVERAGE CONFIDENCE RISK
Big Task 2 4 25 7.2 (8 whole days) 55% 17 Days
Small Task 1 1 5 1.7 (2 whole days) 59% 3 Days

RISK = HIGH – AVERAGE

Both the big task and the small task have about the same low confidence level, meaning that the team sees that there is a wide variance in their possible outcomes. However, if the big task goes bad it could add 17 days to your workload, while if the small task goes bad it will only add 3.

The Confidence is a relative measure, the risk is an absolute size.

When you spot big risks, it is usually because you have a large task. The best strategy is to work with the team to see if you can break the task down into smaller tasks and identify if the risk is the culmination of a lot of small risks that will all need to be managed, or is there one really risky element throwing everything off, which could be tackled up front.

In asking your team to think about things in an range driven by optimistic, pessimistic, and realistic points of view; you have asked them to dive into each estimate more than just giving you a date. You have also give them a vehicle to quantify confidence and risks in the estimations which give you and team essential data for developing schedules and plans.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s