home categories tags applets coaching about rss | Theme: switch to next theme

On Estimating

On September 14, 2018 in notes • 2 minutes read

Tags: software-development • agile • planning • project-management

Table of Contents

• Providing Clear Estimates
• Making Precise Estimates
• Taking it a step further - using probabilities

Providing Clear Estimates

When making predictions or assessments, vague phrases like “probable” or “likely” mean different things to different people. One person’s “probable” might be 60% confidence while another’s is 85%. This ambiguity leads to miscommunication and poor decision-making.

From Superforecasting, page 123, Sherman Kent recommends the following language when dealing with estimates:

• 100%: Certain
• 93% (+- 6%): Almost certain
• 75% (+- 12%): Probable
• 50% (+- 10%): Chances about even
• 30% (+- 10%): Probably not
• 7% (+- 5%): Almost certainly not
• 0%: Impossible

This enables estimators to “think about thinking”, a process known as metacognition, making the forecasters better at distinguishing finer degrees of uncertainty, but can be met with many cultural difficulties.

Use this framework when making forecasts, conducting risk assessments, or communicating strategic uncertainty. The precision forces clearer thinking and more honest communication about what you actually know.

Making Precise Estimates

Back in 2018, I found the following recommendations from sirwitti on estimating, as he moved away from estimating with hourly rates to flat-rate prices, whereas the estimation error should always be heavily on the contractor side.

1. Split the project up in phases and split each phase into work chunks

2. Conservatively estimate the time each chunk will take

3. Estimate and add all project overhead (project management, meetings,…)

4. Add time/budget for all known unknowns (design iterations, testing, bugfixes, deployment,…)

5. Multiply the sum with a factor for unexpected things (things taking longer than expected, technical issues, anything unforseen). Depending on the absolute amount of hours budgeted and on what you know about the project and client this factor could be anywhere between 1.1 (everything should be straight forward) to 2 or even more.

6. Multiply the total sum with your hourly/daily rate

7. “Round” up the total number, depending on the client (smaller or larger company). This could mean to change $16,789 to $20,000 or $6,407 to $7,000

Taking it a step further - using probabilities

The same HN thread pointed to Estigator, a React product to help with probabilistic estimation: you break work into tasks, give each one a range or “up to” or probability-weighted options, and it shows a distribution and summary stats.

The original was by Angent Ltd.

I rebuilt it as an applet on this site: Estigator applet - you can use it to estimate various parallel workstreams with sequential tasks within them.

References

• sirwitti, comment on Ask HN: Developers, how do you estimate projects and write proposals?
• Estigator (archived) — probabilistic estimation tool, © 2018 Angent Ltd
• Angent Ltd (archived) — original Estigator publisher
• Superforecasting - book by Philip Tetlock and Dan Gardner on the Art and Science of Prediction