Why I believe in Estimates #Agile #Science #NoEstimates

It became clear to me the other day that my belief in estimates was not due solely to my previous project experience. It was not due to any brain-washing or “boiling of frogs” that had occurred to me as I was on more traditional projects. My belief in estimates is deeply rooted in another belief I have. The belief of Science and the Scientific Method.

The Scientific Method

Wikipedia briefly describes the Scientific Method as the following:

“The scientific method is a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge.To be termed scientific, a method of inquiry must be based on empirical and measurable evidence subject to specific principles of reasoning. The Oxford English Dictionary defines the scientific method as: “a method or procedure that has characterized natural science since the 17th century, consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses.”

The chief characteristic which distinguishes the scientific method from other methods of acquiring knowledge is that scientists seek to let reality speak for itself,[discuss] supporting a theory when a theory’s predictions are confirmed and challenging a theory when its predictions prove false. Although procedures vary from one field of inquiry to another, identifiable features distinguish scientific inquiry from other methods of obtaining knowledge. Scientific researchers propose hypotheses as explanations of phenomena, and design experimental studies to test these hypotheses via predictions which can be derived from them. These steps must be repeatable, to guard against mistake or confusion in any particular experimenter. Theories that encompass wider domains of inquiry may bind many independently derived hypotheses together in a coherent, supportive structure. Theories, in turn, may help form new hypotheses or place groups of hypotheses into context.”

The Scientific Method is composed of 5 distinct steps:

Note: I am using a little bit of poetic license on the application of the Hypothesis step to a Software Development project. Please forgive me. 🙂

As Khan would say, “Let us Begin”

Formulation of a Question – The questions usually describes an explanation of an observation or an open-ended question for which an answer is desired? For example, “Why is the sky blue?” or “How long will it take to redevelop a financial re-balancing engine?”

Hypothesis – The hypothesis is a conjecture based upon the knowledge of formulating the question and past experience and expertise of the people involved. The Hypothesis can be very specific in the case of Scientific experiments (“The Sky is Blue because of the density of the Atmosphere”) or broad constraints and assumptions in the case of Software Development. (“The most efficient way to develop a financial re-balancing engine will be to have a team co-located with a dedicated client, using Agile methods, adding extra hours for learning new technology, and counting on only 6 hours a day”)

Prediction – The prediction involves determining the logical consequences of the Hypothesis. In the case of Software Development, if all the situations/assumptions hold in the Hypothesis, what would be the end result? How long would it take to redevelop a financial re-balancing engine? Usually the prediction is based upon past experiments and the skill and expertise of the team making the prediction.

Testing – This is an investigation of whether the real world behaves as predicted.

Analysis – This step involves reviewing the results and determining how to best explain the data. Why did we take two months longer to deliver the new financial re-balancing engine? How can we leverage this knowledge into the formulation of the next questions formulation? If the delay was caused by Regulatory Requirements, how can we ensure that information is taken into consideration in the future and become part of future Hypothesis?

Agile Estimation

Now before anyone paints me with the “You are asking for a detailed estimates and you will be micromanaging your team to those estimates in a Death-March” brush – I’ve always said those symptoms are due to bad management and not caused by estimates. What I am proposing is the minimal amount of estimates.

So why do I think estimates are important?

I believe there are a few problems caused by not doing any estimates:

1) We don’t know if a project has an acceptable Return on Investment before we have potentially wasted money. The only question will be how much money we waste. Many projects may only make sense from a ROI point of view  based upon the estimate. The Minimum Viable Product may be more that the Return on Investment allows for. In that case, we shouldn’t even start the project.

2) Estimates make you think through possible factors and can help refine the solution. When you need to create an estimate you do apply more rigor and this helps to harden the solution and minimize future rework.

But most importantly….

3) I have faith in the Scientific Method. It has driven and developed the society we live in. I find it ironic that in the Computer Science field we are now embracing not following the Scientific Method.

The Goal of the Scientific Method has always been to better understand reality and to make theories and predictions that become better and better at describing and predicting reality. The results of that analysis are then reviewed by their peers and used to make the future theories and predictions better. This feedback loop is crucial to science. Interestingly enough, by Agile proponents recommending No Estimates they have eliminated a feedback loop across projects that provide feedback on how we plan and estimate. Other Agile teams can/will encounter the same challenges that another team faced without a feedback mechanism that highlights divergence from an estimate or schedule. Without an estimate or schedule, the team may not even think of it as a divergence…

The questions may be one of scope.

1) If your primary concern is your current project then creating estimates may provide less value. After all, you are going to hit those issues anyway.

2) But if your primary concern is a corporation, enterprise, and industry – then estimates have much more value. Multiple projects that shouldn’t have been started can bankrupt a company, projects with accurate estimates can help to make sure the company works on the right projects. And for consulting companies, making the same mistakes on projects estimates can send clients scurrying to your competitors.


The Grand Unified Theory is a great example. It still isn’t complete and scientists are working to refine and improve the theories by reviewing past works and designing new theories. These past theories weren’t lies told  by Einstein, Hawking, and Penrose. (That is the language the No Estimation supporters frequently use) No, they have been a theory on reality. Just like estimates are a theory on the reality of a project. And yes they are incorrect. Can anyone think of a scientific theory that was proposed that was right the first time?

Maybe we should get Estimates a new Public Relations campaign and call them project theories.

But we do need them. F=M x A and a cure for Polio tells me so.