How might Estigator help you?
Estigator was originally created to help developers and contractors. For those situations when managers ask “how long will it take to…?” Or when a potential client asks, “the daily rate sounds reasonable, so how much should we budget to get x done?”
Estigator is fundamentally a tool to help with communication. In discussions about estimates, it’s easy for both parties to take away different conclusions. Over simplification (“but you said it’d only take about three days”) and the temptation to over-promise (“I reckon it could be done in less than two days if we trim the requirements”) can lead to misunderstandings and disappointment.
The challenges intensify when totals are involved:
“About three days for work package 1, then about four days for work package 2.”
“So, seven days, right?”
Well, not exactly…
The app was created to facilitate communication; to enable sensible, quantitative discussions about who was taking risk, and how much. Estigator takes the discussion from “it’ll take about three days” to “the job has a 20% chance of running to six days or more”. It gives a fuller picture.
During Estigator’s development, it became clear that the maths that’s used for totalling up uncertain task durations is identical to that for summing up totals of all kinds. It could be used for predicting budgets (switch the unit from “hours” to “dollars”), scores (“points”), nearly anything.
The rest of this page consists of small extracts on the subject, taken from an excellent book with the subtitle “A Code of Conduct for Professional Programmers”.
Recommended reading
Extracts from Chapter 10 of “The Clean Coder” by Robert C. Martin.
ISBN-13: 978-0-13-708107-3
“Estimation is one of the simplest, yet most frightening activities that software professionals face. So much business value depends on it. It is the primary wedge that has been driven between business people and developers.”
“Business likes to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound.
Commitment is about certainty. An estimate is a guess. The reason we are often so bad at estimating is because we don’t understand the true nature of an estimate.
An estimate is not a number. An estimate is a distribution.”
“Professionals draw a clear distinction between estimates and commitments. They communicate the probability distribution of their estimates as clearly as possible, so that managers can make appropriate plans.”