A while ago I wrote a blog connecting my beliefs with estimates to the Scientific Method. I still believe in the position I proposed, but I have had the unique opportunity at SDEC13 to be exposed to different opinions and alternatives. I attended a fantastic session by Chris Chapman title “The Great Canadian #NoEstimates Challenge”.
At the end of the session, I felt more informed of the validity of both sides of the discussion.
Recently I came across some reading that clarified my thinking on the subject. That reading was the distinction between Deductive and Inductive Reasoning.
Deductive Reasoning vs Inductive Reasoning
“Deductive reasoning (top-down logic) contrasts with inductive reasoning (bottom-up logic) in the following way: In deductive reasoning, a conclusion is reached reductively by applying general rules that hold over the entirety of a closed domain of discourse, narrowing the range under consideration until only the conclusion is left. In inductive reasoning, the conclusion is reached by generalizing or extrapolating from initial information (and so induction can be used even in an open domain, one where there is epistemic uncertainty.” – Wikipedia
My Belief System
I guess I believe in estimates because I believe in Deductive Reasoning. I believe that Deductive Reasoning can be applied to almost any domain. There are some exclusions in the pure Research and Development areas, but that is not the situation for most Software Development projects. I’m not saying that the Software Development domain is simple and routine like construction, but it also isn’t a pure Research and Development domain. For 99% of the projects it sits solidly in the middle. As because of that reason I believe that Deductive Reasoning should be used on Software Development projects.
It should be noted I don’t believe in Deductive Reasoning only for estimating. I also believe Deductive Reasoning should also be used when designing the solution and architecture and scheduling the project. If some Deductive Reasoning is not applied for the solution architecture, we do not have “general rules that hold over the entirety of a closed domain of discourse”. Put in a different way, we run a greater risk of having an inconsistent solution and architecture. If some Deductive Reasoning is not applied for the creation of the project schedule, we will not provide the external visibility that will be required to co-ordinate with other people. (Yes – that includes budgeting)
The latest trend in the No Estimates land is not to estimate stories, but just to count stories. This is still estimating with a different formal system. So I agree 100% that this is a viable alternative. It is a great example of having “”general rules that hold over the entirety of a closed domain of discourse”
I guess the question is whether the negative aspects of estimating (and there are quite a few), are offset by the benefits of Deductive Reasoning.
For my money, I believe they are as predictability and consistency provided by Deductive Reasoning is very valuable to clients and external teams. Although no estimates can help the development team perform better, we must be careful not to sub-optimize and not provide the predictability and consistency required by the entire team.
When we are asking whether we estimate we must remember that the value is defined by the entire team, especially the client.