The Five Laws of Software Estimating

A blog post titled "Five Laws of Software Estimating" contained several?bunk?ideas. Let's look at each of them

1. Estimates are a waste

Time spent on estimates is time that needs to be spent delivering value. It's a zero-sum game regarding how much time developers have to get work done – worse if estimates are being requested urgently and interrupting developers who would otherwise be "in the zone" getting things done. If your average developer is spending 2-4 hours per 40-hour week on estimates, that's a 5-10% loss in productivity, assuming they were otherwise able to be productive the entire time. It's even worse if the developer is part-time or can only spend part of their workweek writing software.

The estimates aren't for the developers, they're for those paying the developers.?

Estimates can help developers plan work sequencing, needed staffing, and other?resources, but to say they detract from their development effort reeks of hubris.?

Writing software for money requires money to be provided and sales revenue to be acquired to offset that cost. This is a business discussion, not a?coder's?Point of view.?

2. Estimates are Non-Transferable

Software estimates are not fungible, mainly because they are a corollary of team members' being fungible. This means one individual's estimate can't be used to predict how long it might take another individual to complete a task.

This is the basis of Reference Class Forecasting. Write down what the estimates were when you made them, classify the estimates by the categories?of software, put those in a sprad sheet and use then again when you encounter a similar?class of software. This is standard software engineering practice in any mature organization. CMMI ML 2 and 3 process areas.?

3. Estimates are Wrong

Estimates aren't promises. They're guesses, and generally, the larger the scope and the further in the future the activity being estimated is, the greater the potential error.

This is one of those naive statements that ignores the mathematics of?estimating.

Estimates can be guesses, and that'd be bad estimating. Refrain from doing stupid things on purpose. Read?Estimating Software Intensive Systems?and learn how to estimate, and?then you won't be?saying naive things like?estimates?are?guesses.

4. Estimates are Temporary

Estimates are perishable. They have a relatively short shelf-life. A developer might initially estimate that a particular feature will take a week to develop before the project has started. Three months into the project, a lot has been learned and decided, and that same feature might now take a few hours or a month, or it might have been dropped from the project altogether due to changes in priorities or direction. In any case, the estimate is of little or perhaps even negative value since so much has potentially changed since it was created.

5. Estimates are Necessary

Despite the first four Laws of Estimates, estimates are often necessary. Businesses must decide whether to build software with some idea of the cost and time involved.

Yes they are. Making decisions in the presence of uncertainty means making estimates of the outcomes and impacts of those decisions on future.Reference

So before applying any of these ideas, ask a s simple question and get the answer.

What's the value at risk for NOT estimating the impact of your decision?

Why 3 Points Estimates Create False Optimism

A recent post at PM Hut describes capturing 3-point estimates for schedule. This is an example of Yogi's quote in action.

In theory there is no difference between theory and practice. In practice there is. - Yogi Berra

While teaching about the three-point estimate process—minimum, most likely, and maximum—may be appropriate in the classroom, it is inappropriate in practice. This does not mean there are not dozens of people out there doing this. It doesn't matter how many people teach this or how often it is said; it's simply not good practice.

Here's why:

• If you ask someone to estimate how long something will take by having them think about the Most Likely duration, they will, for the most part, actually think about the "average" duration. The most likely duration is the value that often appears when you ask a group of people the same question. The Most Likely is the Mode of the samples of that question. It is the value that occurs most often.
• The duration might differ when you ask someone to estimate the most negligible value. Or ask them what the duration's most value might be, and you'll get statistically significant different values, depending on the order you ask that question. This understanding has been developed by many organizations, from the US Navy to petroleum engineers estimating the contents of gas reserves.

Here's a reminder of how to discuss the three values in our probability distribution.

Would you happen to know what the Point HerePointDo is? Do not ask for 3-point estimates of duration and cost; ask for "variances" of the probability distribution around the Most Likely number. In the worst case, ask for variances around the Mean (the average). But care must be taken for the measure of the Mean. Since the Mean is a value formed by adding all the possible measures, it is subject to variance. Most Likely - the Mode - is a simple counting of the most recurring observed value - it is ordinal.

Why Is This Important?

When you ask for the Most Likely, High, and Low, you can get up to 27% estimating bias on the estimates. This bias can be favorable or unfavorable. No matter, it is a bias.

To do this for duration and cost, construct a variance ranking process. Here's a sample table.

Now, there are several essential things about this table:

• The risk level classification is not a number; it is a letter. This avoids the natural tendency to do arithmetic on the risk ranking. This is a standard failure mode for anyone using the PMI style risk management. Take the probability of occurrence and multiply it by the consequential outcome to get a risk rank. NOT.

Both the probability of occurrence and the consequential outcomes are probability distributions, represented by integral equations. Multiplication is not an operator on integral equations - except in their Laplace Transform representations.

• The risk classification descriptions represent the project's operational aspects for a specific technology or process. This means that the words in the classification column can change depending on the problem domain. For example, a risk classification D may have different words and variance ranges for human-crewed space flight than a Risk Variance D for an Oracle ERP system rollout.

What we need is a table like this for every major risk category.

A similar table can be built for the consequential outcomes. Then and ONLY then can the risk matrix be constructed.

The final advice is that risk ranking regarding variance should be geometric.

You want to do this because the separation of differences is not linear; it must be geometric. The scale 1, 2, 3, 4, 5 means that the difference between 1 and 2 is 100%. The difference between 4 and 5 is 20%.

Here's a Live Example

The picture below shows how to connect the dots—from NOT doing three-point estimates to making probabilistic impacts for the probability of occurrence and the consequential outcomes.

So:

• No three-point measures were asked of the engineers - only variance estimates for each class of risk.
• No arithmetic between occurrence and impact
• Narratives of the measures (in the NASA example above, they use numbers - not good - use letters)