Why I Like #Estimates #NoEstimates #Visualization

There I said it. I like estimates. I like estimating. I think they provide value to my team and the customers. I will attempt to explain why is this Blog post.

1) Estimates make me think through a solution

I liken estimating to the visualization successful sport athletes do. It is the visualization and mental practice of what is likely to happen. Great athletes use this practice to anticipate issues and try to make every game as successful as possible.

When I estimate I am forced to examine project details and technology and think through the deliverables at a detail level and how we would build them. This helps to identify issues early and give the team and client lead time to decide on a resolution. When you discover issues late in the game, your options are limited and client anger usually follows.

If we just start building without doing detailed design and planning, the chance of project issues increase. I agree that you can do that detailed design and planning without estimating, but due to how estimates are used traditionally they result in people doing more detailed design and planning. This is because people know they are used for financial decisions and require some level of certainty. Estimates matter.

Now I don’t subscribe to estimates being used as promises and never being able to update the estimates. In fact, project estimates need to be updated weekly as new facts are encountered. This frequent updating of estimates needs to be discussed and agreed to before the project starts. Clients need to agree estimates are estimates, not promises or actuals.

2) Estimates create a shared understanding

One may disagree on the value of estimates. But I think everyone agrees that the discussions that occur while estimating are invaluable. These discussions create a shared understanding throughout the entire team. Yes I am assuming you are estimating with your entire team. If you are creating estimates for others then you have bigger problems than just estimates.

3) Estimates allow the clients to validate Minimum Viable Product before we start

Although the No Estimates approach and Story Slicing will allow the clients to have input and control over the work as it proceeds, it is still possible to start a project without the ability to complete a Minimum Viable Product with the available budget. Once you discover you can not deliver the required functionality, you may have wasted considerable budget. It is recommended that projects should not be started that have such a small profit margin. The reality is that most Information Technology projects have a small profit margin.

Will estimating Minimum Viable Product provide a iron-clad solution to this? Definitely no, we will estimate incorrectly at times. But as stated in point 1. The process of thinking through the problem does increase the chances of success.

4) Estimates allow Clients to allocate post Minimum Viable Product budget to other initiatives

In addition, the clients may want to allocate some of the post Minimum Viable Product budget to other initiatives and not to wait to see how a project goes just in case the project needs it. Clients are not going to reserve large budgets just in case an Information Technology project need it. Clients have a very limited budget and there are always more initiatives than budget. Allowing clients just to stop projects at any point does not recognize the lost opportunity cost by not starting additional initiatives that could have placed them ahead of their competitors.

One can even say that while No Estimates works well for one project, it doesn’t allow for the discussions and trade-offs required to manage a large portfolio of projects where the clients need to maximize the number of Minimum Viable Products delivered each quarter.


These are my reasons as to why I like estimates. It should be noted that I don’t recommend doing detailed estimates in any way shape or form. These estimates should be higher-level estimates that are:

1) At a deliverable level

2) Can be updated every week

3) Are created by the developers and clients

When focusing on Minimum Viable Product is the wrong thing to do #Agile #MVP


There isn’t too many things more sacred than Minimum Viable Product in the Agile circles. Maybe Planning Poker, Automated Testing, and Continuous Integration. But usually Minimum Viable Product is also right up there. What if I told you that focusing on Minimum Viable Product is sometimes the wrong thing to do? Would I be branded a heretic?

Well it is – sometimes.

Client Focus

I sometimes find that we in the Agile community are falling into the old traps that haunted the traditional Software Development Professional – the fact that we know what is best for the client. I see comments like we shouldn’t create any documents or create any estimates because they are waste. Usually these positions are written from the point of view of the Software Development team. But we as developers may define value and waste differently than our clients. We need to understand the context of the project we are in and the situation the client is in and apply our processes accordingly.

For some clients not creating documents may be a waste as they will need to create them for regulatory purposes and it may take them longer to create them after. (In addition to being more error-prone) For some clients, estimates may provide them great value in their forecasting and budgeting process. So while we may think that creating estimates in wasteful, the clients may not share the same view. Ultimately, their viewpoint is the one that matters if we want to be client focused and remain in the service industry.

Our job as Software Development professionals is to provide our expert opinion and highlights the impacts of the decision to the client. If we can’t convince the client of the value of our position, then our position could not have been a strong one to start with.

Our job as Software Development Professionals to to provide all the information to the clients so they can make the most well-informed decision possible. Not to decide for them. Ever.

Minimum Viable Product

So where does that leave us with Minimum Viable Product? How could organizing the project in a way that you could go live during the project be wrong?

Well, what if going live early has no value to the client?

In the diagram above, what if the client definition of value is only realized by being able to transport a family of 5? Being able to structure a project to continue to deliver Minimum Viable Products comes with a cost. If you look at the example above, you can see that so each step up in the viable product chain, we need to swap out some frameworks and functionality for other frameworks and functionality. Structuring a project in this way doesn’t come without a cost.

Now there are many great technical reasons why to want to structure a project focusing on a chain of Minimum Viable Products. They help to address risk and provide lessons learned to improve the product and project as you go along. But don’t assume that it is always what the client wants, needs, or values. In exceptional circumstances, the extra effort to structure a project focusing on Minimum Viable Product may actually be most wasteful that structuring the project in a traditional way.

There might be a series of Minimum Viable Products that could be created to address technical risk, but not to provide any early client value. Perhaps it might be just one prototype early on to address new technology. The important thing is don’t assume it has value for the client.


We must always remind ourselves that the processes and methods we use must return more value for the client than other options and not just fall into the habit of executing every project using all the Agile tools in the tool belt.

After all, isn’t that what got us in the Detailed Work Breakdown Structure, Big Design Up Front mess before?




A case for Contingency #NoEstimates

It seems like everyone has a different view of the role that contingency should play on projects. While some recommend removing it so as to not inflate the cost of features, others feel it is a critical element in the estimation of the project. Some people feel it is best to hide it away in the features themselves, while others like it explicitly separated for clear communication.

One thing is clear to me after many projects that have gone well and poorly. Contingency is required. Contingency is required to portray a realistic image of how the project will go. While many people try to remove Contingency to not inflate the cost of a project, it actually reflects reality.

Contingency is the cost factor of likely issues that the project will hit based upon the experience of the team and company executing the project. To remove contingency would be ignoring the past.

Even the noble attempt to remove contingency and work solely with feature velocity so that the team and the client can jointly work on the prioritization of features is misplaced. Removing that contingency will change the decisions made by the business early on. Without the contingency , the client may feel that they will get more done and will add more scope. Then once issues start being encountered, it becomes very apparent that the client won’t get everything they need because they added items early on based on the perceived velocity and lack of need of contingency.

For example, Let us say we have 100 features that we need to accomplish and based on the first month we determine we appear to have a velocity of 20 features a month. The project is required to go live in 6 months. This appears to be a solid 5 month project. Early on in the project we encounter 12 features that the client would also like to have. So we add them since we have an extra month. What we find a couple of months in is our velocity is really 16 not 20. (as we encounter some more difficult features) Now we determine we will only be able to complete 96 out of the 112 features we have. Although we are working in priority sequence, there probably are some features that the client can’t go live without.

We have a pickle. All because we didn’t use contingency to reserve budget and schedule based on realities.

To me No Estimates sometimes feels like doing Physics problems without friction. While the equations hold and produce logical results, they don’t reflect reality. And once you add friction to the equations, the change in the results can be quite dramatic. If No Estimates work for you, then you are probably more in the product rather than project space and I’m envious. 🙂

But for the most part most of us need to deal with friction.

While No Estimates is intriguing, the removal of the analysis and incorporation of contingency is dangerous and can be deadly. While past velocity is an important factor, future planning and learning from the past is equally important. To manage mathematically based on past history is overlooking one very key factor – prior projects and experience. As we know most of the issues happen later on the projects. Contingency isn’t linear. Planning with only velocity requires contingency to be linear. In reality, we adapt to early velocity and make scope decisions based on that. They when issues hit that require contingency, it is no longer there as we have made decisions based upon what we think we can do based on past velocity.


Contingency isn’t evil or bad. It doesn’t inflate the cost of a project. If anything, it is the one thing that takes a paper plan and makes it real. Leave it out at your own peril.

My #NoEstimates Apology and Epiphany #NoInventory

I was lucky enough to discuss ideas and thoughts with Woody Zuill last week on No Estimates. To be fair, I wrongly assumed that an upcoming No Estimates workshop was somewhat monetizing the No Estimates ideas. After talking to Woody, it became very clear that this was something requested by people interested in hearing Woody and others speak. It was not initiated by the No Estimates movement and my assumption was incorrect. Just goes to show you than you should always seek to understand first.

For this I apologize.

To Woody’s great credit he still agreed to meet with me over Skype and agreed to talk about Software Development and share ideas. It was a great session with many ideas shared about pains and gains we both had seen on Software Projects over our many years.

No Inventory

About halfway through on conversation we started to discuss projects where I had to estimate. I discussed how I felt the estimates were required but also that I saw the draw backs of estimating. I also felt the clients liked the estimates and I confessed that I actually like the estimates as well. Then I made an observation. The more inventory one had on a project, the more detailed your estimates were. Whether that inventory be documents or code, there certainly seemed to be a linear or possibly even exponential relationship.

For example:

  • If you can deliver in less than 2 weeks, estimates are not even required
  • If you can deliver in less than 2 months, deliverable level estimates are enough
  • If you can’t deliver in less than 2 years, break out the Work Breakdown Structures, Gantt charts, and earned value calculations


Then it really struck me. (and I think both of us) Yes we would like to reduce, minimize, or eliminate the requirement for estimates. But that can’t be done in isolation. We can’t take an ERP implementation that will be implemented in 3 years in a big bang method and say we don’t need estimates. Why? Because the business needs to make decisions for that three-year period and budget decisions. No Estimates can’t happen in isolation. When we propose No Estimates, what we are really proposing is No Inventory. Once we have No Inventory, we will lessen or perhaps eliminate the requirement for estimates.

You see it is quite ridiculous to propose to eliminate estimates when a project has a huge amount of inventory. The business requires them to make decisions and predictions because they won’t see the results of the inventory for a long time. But if we could turn that inventory over in a more timely manner, one of the main needs for detailed estimates goes away. I’m not saying that the estimates totally go away, but they certainly become less detailed and less critical.

For me what this epiphany meant is that instead of talking No Estimates, I’m going to talk about No Inventory. On all my projects the question is going to be how can we go to production quicker and faster. If we can do that, I believe our estimate will become less detailed and the estimates may perhaps even disappear once we are delivering fast enough.

For my projects, I’m not sure estimates will totally disappear. But the goal to keep them at a deliverable level by delivering early and often is a step in the right direction. The other advantage to minimizing inventory is that it also minimizes the size of the estimates and the risk to the project. If I miss the estimate on a two-week inventory, no problem. I can learn and fix it in the next two weeks. If I miss the estimate on a two-year inventory, now I have a problem.

No Inventory

My #NoEstimates disappointment

I must admit I usually come right in the middle between No Estimates proponents and the traditional estimators. I usually like the process of estimating on my projects, but I certainly see the downsides of such estimates.

I also do think estimates and no estimates and Lean Start up are not mutually exclusive. I can still do estimating on a project that I am executing in a Lean Startup method. Sometimes I think we search too much for discrete and absolute answers.

Anyway, that wasn’t what disappointed my about No Estimates this weekend. Rather it was a link to this announcement.

My Opinion

If you haven’t clicked on the link, it is an announcement to a No Estimates workshop in October 2014. The link also asks for questions to be submitted to be answered in the session.

So why did this disappoint me?

I’m always disappointed when the pursuit of new ideas, methods, and practices become an economy. I’ve asked some questions of the presenters before and it was mentioned that they would add it to their list of questions and perhaps they would do a future blog post on the subject. Now it appears to get those answers I may need to attend a workshop in Europe. I’m disappointed because I was hoping to hear the answers to those questions other the next few months. Now perhaps I’m wrong and hopefully this workshop will not hinder the flow of ideas over the next few months. But there still does seem to be many questions out there that are unanswered.

For example, “What you you recommend I do first to try No Estimates on a project?”

I Wonder

I also wonder if the No Estimates workshop will be done in tune with No Estimates principles? For example:

1) Will a full price for the workshop be estimated and required up front? Can I attend for a day and leave for a day if the value I expect isn’t being realized? Can I pay day by day?

2) Will the workshop have a set agenda or can the attendees define the agenda in the first hour collaboratively?

3) Couldn’t we try to answer a few of the questions listed first and validate people would get value out of the session before committing a week of time, considerable training budget, and fossil fuel to jet to Europe?

It almost feels like a week-long workshop is against the principles of No Estimates.


I’m disappointed as I fear there may also be No Estimates certifications down the road ala PMI and Six Sigma.

But I fear that No Estimates will join the establishment of training courses and specialized consultants. No Estimates to me was always about challenging the establishment and not joining the establishment.

As Obi-Wan said in Revenge of the Sith – “You were the chosen one! It was said that you would destroy the Sith, not join them. You were to bring balance to the force, not leave it in darkness.”

Hopefully I’m mistaken.




My @WoodyZuill experience #NoEstimates #Agile

Recently I was able to attend a presentation by Woody Zuill at an Agile Winnipeg meeting. Before I get into my opinions of the meeting, I’d highly recommend you attend a session by Woody if you have the chance. Woody is intelligent, respectful, and insightful in many different areas of Agile and Software Development.

Although Woody might be known for his No Estimates thought leadership, this presentation was more on the Agile mindset. (In my humble opinion) There were several points that resonated with me from this presentation. Early on in the presentation Woody coined the phrase “Baby Steps to Better” while discussing projects and how he strives to improve projects and project teams. I thought that if nothing else, what a fabulous principle to take away from this presentation and live every day on my projects.

Agile Manifesto

My favourite part of the presentation though was a group exercise that Woody led in relation to the Agile Manifesto. Woody very simply asked everyone what the word ‘Over’ meant to them in the Agile Manifesto.  For example, what does over mean to you in this statement?

Working software over comprehensive documentation”

Everyone scurried away writing down their thoughts. Answers filled the entire spectrum. Such as:

  • Items on the left are preferred to items on the right
  • Items on the left are given priority to items on the right
  • Items on the right should not impact items on the left
  • and so on…

Woody then proposed a fifth statement not in the Agile Manifesto to provoke thought:

“Healthy Lifestyle over eating fast food

Wow. Maybe it isn’t a continuum?

My opinion

My first thought was that this was a brilliant question to ask. I also thought it was even more brilliant to frame the discussion with the healthy lifestyle statement.

I thought about it and offered my thoughts to the group. As usual, my thoughts were somewhere in the middle. I offered that both are important but it all boils down to how often you do the item on the left compared to the item on the right. Can I have a healthy lifestyle if I eat fast food once a month? Sure. Can I have a healthy lifestyle if I eat fast food daily? Not a chance.

So can you be agile if you always follow a plan or demand comprehensive documentation? I would say no. There are some circumstances where the right might be required, but if you are always finding a reason to do the right side. You may want to ask yourself if you are truly being agile. There also may be valid reasons not be be agile based on the client, team, and problem at hand. You also shouldn’t feel bad if you can’t be agile. (My opinion)

But be aware if you are doing items on the left and right equally, you probably aren’t totally agile.  And that is OK.

But what I love about this exercise is the clarity it provided to me on what I should strive for on my projects.

Full Disclosure

I like estimates. I’m not a fervent No Estimates proponent. I find myself doing the minimum amount of estimates possible, but still usually doing estimates.

But I do absolutely respect people who challenge me to be better and think differently.

Thanks Woody. Pleasure to meet you.


My #Agile pet peeve – Agilitus Extremus Argumentus

agilitus extremus arguementus

Let me start off by saying I do believe in the Agile principles and running projects in an agile way.

But, I’m not an extreme Agilist that believes in not estimating and other aspects of Agile that tend to lead more into the sociology and psychology of individuals.

For example, I don’t believe estimating is lying. I also don’t believe the creation of a document is all waste.

“Oh so now I need to estimate what I do for every 15 minutes?”

My frustration with some Agile proponents is the extreme reaction they have to client requests. When it is mentioned that we now need some level of estimating, they will soon recount a story with a 12,000 line Work Breakdown Structure and micro managers that bring back fond memories of the Spanish Inquisition. If they bothered to ask, the client requested that we need to have a baseline for comparison that required 10 buckets of time and a weekly schedule to allow the clients to plan a roll out strategy. Even worse, they will mention that all estimates are lies and how developers will now imprint on that lie like a newborn duck. Frankly, I have more confidence and faith in the maturity level of developers I have worked with than that.

Likewise, any request to create a document is again met with a tale reminiscent of the Count of Monte Cristo where the analysts were locked in a basement creating 200+ page specification documents while water slowly dripped on their forehead. If they bothered to ask, the client requested a high level document that they can review before we develop too much code to ensure we haven’t missed any key requirements.

My solutions are usually grounded in the grey area between the traditional approach and the agile approach. I find that is the right level of ‘Enough-Ness’ that provides the appropriate value given the risk.

Are there psychological truths behind these concepts that extreme Agilists present? Absolutely, but we need to be aware of these truths and determine how best to manage them in projects. We must do this by not exaggerating and fear-mongering. These truths also provide excellent information on why we should be careful about estimating and documenting, but not to exclude them 100%.

As Agilists we need to be careful we empathize with the clients as much as with our development teams. (If not more) Sometimes the Agile extreme point of view is grounded so much on the development team, that it does it at the expense of the clients.

In our Software Development past, I remember the attitude from IT departments that we know better than the clients and we will deliver what we want and the clients will use it. It took us a long time to become client-centric and we need to be very careful this arrogance doesn’t transfer from the solution we deliver to the processes we use.

The client always defines value and knows best.


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.

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.

The Selfish #Agilist

As I was finishing my last post on what I termed Agile Sketches, there was a second point that occurred to me that I thought was relevant and probably deserved a separate post.

I see a lot of recent comments and posts that propose we provide no estimates, no deadlines and do no planning. While some of these discussions are valuable and the questions they ask are important. I wonder if Agilists are becoming selfish.

It seems like we are proposing to move away from any practices in which we have to provide predictability and where we could be wrong. In their place are principles and practices that limit any predictability so that we will not likely be wrong.

Estimates are difficult? No problem lets not estimate at all…

Agreeing to a schedule and deadlines can be difficult? No problem we won’t have deadlines at all…

The Problem

The proponents of no estimates and no deadlines seem to be focusing on the requirements of developers and the development process at the expense of the clients. Have we become focused on what processes are best for us or the client? I agree that actions over planning will typically return the most value, but eventually there is a tipping point where the total elimination of these practices can have a detrimental effect. We always have to remember that value is always defined by the client. Do we have clients asking us for no estimates and no deadlines?

The Psychology

It may surprise you that I agree with the psychology of no estimates and no deadlines. Yes, it is difficult to have estimates and deadlines. Yes  both estimates and deadlines can have adverse effects on individual and team dynamics. But we as professionals need to not just eliminate things that are difficult, but to learn how to manage them so we return the most value for our clients and teams. Most importantly, we must always support the practices that deliver the most value to the clients.

Being Brave

To avoid becoming Selfish Agilists we need to rediscover our bravery for being wrong. I sometimes hear that people refuse to give estimates because they would be lying to the clients. At this point we need to remember the immortal words of George Constanza.

“It is not lying if you believe it to be true”

Yes, when we give estimates we will be wrong, but through the act of estimating we can hone our estimation skills and be more and more accurate. We are not lying, we are giving our expert opinion and we will be wrong. And that is ok.

Our team mates will also give estimates and deadlines and they will be wrong… and that is ok as well…

But the act of being brave and putting our opinions forward are what we do as professionals. It isn’t easy and managing the expectations once these estimates are known is also not easy at all.

I see a long continuum of estimating solutions.

At one end you have the detailed estimates with a work breakdown structure and bad management like micro-managing team members. Due to the excessive planning and management you deliver less value to the client.

At the other end you have no estimates and limited predictability. This also delivers less value to the client who requires some predictability.

But in the middle, you can have environment where people give their honest opinions on what it will take to get to end of job. Clients get the predictability that maximizes value. The consequence is that more discussions are required when new things are uncovered and learned and expectations need to be managed. It is never anyone’s fault, everyone is doing the best they can and we are constantly learning. This environment takes the right type of leaders, teammates, and clients. And managing the relationship is not easy. Like all good relationships it takes a lot of hard work.

But are we about doing whatever is easiest or what is in the client’s best interest?