A #NoEstimates Second thought #PMOT #Agile

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)

Story Slicing

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.


Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

One thought on “A #NoEstimates Second thought #PMOT #Agile”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: