#NoEstimates motivations

I thought it would to be interesting to discuss the motivations behind No Estimates rather than the argument as to whether they are required or not. The motivations due go some insight into why they are being provided as an option after all. As I see it there seem to be three primary motivations behind No Estimates:

We don’t want to be wrong

IT professionals are first and foremost caring people who honestly don’t want to let people down and have to inform them that they were mistaken. In this case, it is much easier to not have to give them an estimates which we know is probably wrong. No one ever likes to have the meetings where we need to request weeks of additional effort and thousands of additional budget. The business may think that IT doesn’t care as the dollars are not from the IT budget, but IT really does take these overages seriously and hate to make these requests.

We feel that estimating itself is a waste of time and effort

We also have been on projects where estimating has gone horribly wrong and estimates were way too detailed. Excessive time was spent on estimates in the thought that additional analysis would result in more detailed estimates and a better project plan. IT has learned that estimates should be less detailed, but still those memories seem hard to forget.

We feel bad estimates will led to bad projects and poor quality

Finally, we feel that once given, estimates will be imprinted on the clients and everything else will be sacrificed in order to abide by the estimates. Weekends, personal time, quality, documentation, everything will be sacrificed so we can meet the vastly inaccurate estimate provided at the start of the project when we knew so little.

Let us agree

So let us first agree that all these reasons are valid and noble reasons. We may disagree whether Estimates are valid, but I doubt believe there can be any disagreement that the motivations behind the No Estimate movement are true and valid.

Would you like fries with your McApplication? #NoEstimates

There is a great difference between a fine meal and McMeal. The fine meal typically has been crafted with years of experience and training by chefs around the world. The McMeal is put together with years of experience based on what people want at 1:30 am in a drive-thru. The fine meal also places forethought as to how the components work together and play off of each other. With McMeals and other fast food meals, you are left to your own devices as to what you would like combine together at the last possibly moment.

Software Development

Similarly, Software Development can create solutions on which great experience and effort is expended determining how the components fit together or we can slap the functionality together for a McApplication. Agile can and has been guilty of creating too many McApplications over the years.

User Story Mapping

User Story Mapping is a great tool, but unless it is followed up by some analysis and design work to architect the solution, we are just visually drawing the new McApplication. While the concepts of delivering in iterations and visually planning the iterations is extremely valuable, jumping into delivering without architecting the overall solution is misguided and sub-optimizing.

If your first project work is cutting code after you have created a User Story Map, you are well on your way to creating the next McApplication.

We always need to remember we are professionals committed to creating, designing, and delivering the best solution to a business problem, Sometimes this may involve providing counsel to clients on why some stories should not be done, why some stories should be done later, why some stories need to be done now, and why some stories that they haven’t thought of need to be added.

Client priority rules the day of course, but if we just do what the client identifies without providing our expertise, we are no longer professionals. We are just order takers.

To avoid being just order takers we usually need to do some detailed analysis on what a story means and how it needs to be implemented. Just capturing the highest ‘placeholders’ to discuss functionality means you are creating your architecture as you go along. Yipes.


Which brings us to #NoEstimates.

No Estimates does not focus on creating a better solution. No Estimates has been created so that the project can be forecasted. It proposes nothing to help create a better solution to a problem. Even worse, when No Estimates is followed to the letter, it can even absolve the team of project leadership duties.

No Estimates proposes that we will just work on what the client wants, when the clients wants it and we will stop when the client wants to. It overlooks a key responsibility of project teams to save the client from themselves with our experience and expertise. Agile sometimes seem to shy away from tough discussions that should happen early on projects. Some projects should never start.

Agile proponents forget that not only should code to tested early and often, but incorrect client concepts should also be. If we are taking direction on a client priority that we know is wrong and will result in a lesser solution, and we haven’t done everything we can to change their mind, then we are not Agile.

No Estimates proponents will probably state that all those things should be done on a project in addition to No Estimates, but by not putting design and architecture front and centre it is clear they primarily value forecasting.

Due to this, the type of solution you will get out of a No Estimates projects will probably be a McApplication rather than a fine meal and you’ll probably be hungry for a new solution before long.

Solution Leadership and healthy adversarial discussions over difference in opinions is not valued highly on No Estimates projects. The focus is on  forecasting and doing whatever the client want to do next….

Would you like Fries with that?




Are #NoEstimates #UnCanadian ?


Yep, I’ve come to realize that part of my trouble to rationalize the No Estimates movement is that they are UnCanadian. There are some things that become a part of you when you live and Canada and especially in the Canadian Prairies. Let me explain.


As Canadians in the middle of the continent, schedules define our lives. It snows in late October and is bitterly cold December, January, February, and March. If I didn’t have a schedule that let me know spring will arrive in late March I am sure I would go crazy. In many ways, a schedule is the only thing holding our psyche together when we are shoveling 30 centimetres of snow with a windchill of -40. Like how can it possibly snow when it is that cold? We as a nation as obsessed with weather forecasts. If Meteorologists turned up tomorrow and said they were not forecasting anymore beyond today, I would go to some dark, dank corner of my mind in February.

I need a schedule. I need it to give me hope. 🙂


When you live in a country this vast, a map is a requirement. Trust me, the last thing you want to do is get caught in some small town with out a Tim Hortons in the middle of winter. So as a consequence, I have this inherent need to know where I am in relation to where I thought I would be. In all seriousness, getting caught in the middle of winter not making your destination is a matter of life and death. Getting caught out in the elements will get you killed. More than anything we respect the power of nature.

So I think this Canadian life has ingrained on me that I need a map of the projects I work on. I need it to guide me and in some very real way, I feel lost and vulnerable without it.


Canada is not a Soccer nation. Never will be. Oh sure we have some very talented players now coming up and we will continue to get better, but Soccer will never enthrall this nation like Hockey. Why? I’d hazard a guess is because part of the charm of Hockey is the combination of the skill, tenacity, and toughness. Hockey is the only sport that has a ‘diving’ penalty – where it is a penalty if you are trying to fake an infraction. Yes, I know that Soccer now has a ‘simulation’ penalty, but if you can’t even label the penalty as something shameful, how committed are you to changing the behaviour?

To be blunt, adopting No Estimates because estimates are hard to do and error prone, seems to be like falling down in the penalty area just to get a free kick. Yes, it might be easier and make projects go smoother for developers, but is it right?

No thanks. I’ll carry on, drink my Tim Hortons, fight through tackles and get better at estimating. I’d rather lose the right way than win on a penalty kick.

Why I hate and love #noestimates

I was watching a No Estimates video that someone tweeted recently and I was reminded why I hate and love No Estimates at the same time. The video in question is a No Estimates presentation by Allen Holub. You can find the video here.

I’d like to review the key points of the presentation and discuss the split personality of No Estimates.

0:20 – “We need to stop doing all estimates, now” – As much as some No Estimate proponents say it isn’t about not doing estimates at all, these extreme statements arise again and again. There much be some kernel of truth that they truly believe in this statement. It seems only when no options are available do they concede that you could do estimates if needed.

0:25 – “Estimation has no value at all” – Not your call. The only person that defines value is the client. If the client determines estimates have value, then the estimates have value.

1:01 – “Estimates are always wrong” – Not true. Many estimates are correct. In fact, I’ve had more correct estimates than incorrect estimates in my career.

2:12 – “Estimation leads to dysfunction. Estimation leads to working endless hours without needing to” – This is just bad leadership. Trust me, if you didn’t provide estimates these bad leaders would find other ways to set up a toxic environment. This is not the fault of estimates.

2:55 – “As soon as you have estimates you can’t have a sustainable pace” – Again bad leadership. Estimates are made to evolve and change. Just like other aspects of Agile, our estimates also need to have short feedback loops so we learn from estimates and then modify the future estimates for the project. It is curious how No Estimates proponents are well versed in Agile, but can only envision doing estimation in a waterfall method. It seems like estimates were the only item on their Agile projects that weren’t Agile. If they considered estimation with short feedback loops, I can imagine they would be less adverse to estimates.

3:06 – “As soon as you have deadlines you have people working 18 hour days” – See bad leadership mentioned above. If this is your environment, don’t blame the estimates. There are much deeper problems.

3:23 – “Your boss asks you how long something will take and you have no idea how long it will take, so you make a wild ass guess” – Really? If you have 3-5 years experience and have no idea how long something will take, you might want to find another career. Now there are some components that if you haven’t done before, you really may not know. But for the most part we are building things where we have some experience building similar items in the past. (I exclude from this Research and Development projects. I have been on these and understand they can’t be estimated easily. But those projects are not common.)

5:00 – “People don’t understand how estimates work” – This I agree with. It does take a lot of effort and communication to manage expectations.

6:12 – “CHAOS Report – Projects are late 80% of the time because of bad estimates” – Incorrect and oversimplification. I have been on projects where we were late but that was caused by people leaving, client needs changing, scope creep, and many other factors.

I really do like some of what Allen says in regards to Velocity, but it seems that Allen doesn’t even want to commit to a steady team velocity if nothing changes. In a sense, Allen proposes committing to nothing.

13:29 – “Estimating Software is like estimating Physics – How long will it take to create a Warp Drive” – This is a ill conceived argument. If you are creating something that hasn’t been done before, I agree you can’t estimate it. 95% of all Software Development is a variation on existing patterns and you can estimate it. Not perfectly, but adequately.

14:46 – “There is a disconnect from the people on the team. The catcher is disengaged and need to be engaged” – Again another bad analogy. The catcher and batter are not on the same team. So no, the catcher doesn’t not need to be engaged with the batter’s ritual. The pitcher’s ritual yes. This analogy is just totally incorrect and as a result, is not compelling at all.

15:15 – “There is no difference is estimating and locking your door 7 times” – I hear this from No Estimates proponents now and then. Comparing estimating to known Psychological disorders is dangerous, insensitive, and unprofessional.

15:50 – “Instead of a year long project, how about a month long project?” – Now we get into the part of No Estimates that I love! Enough about bashing estimation. Let’s talk about how we should shorten the feedback loops and minimize inventory. I would propose that we can also do this when we estimate. It just takes good leadership and management of expectations.

19:09 – “Mentally Deranged” – This is similar to my comment earlier about comparing estimating to true Psychological Disorders. This is just unprofessional and terribly insensitive.

21:32 – “The Business decides what to build and you decide how long it will take” – Agree 100%. Most of the previous bad examples seem to propose environments where the managers determine the estimates. I have never been on a project like that. Every project I have been on has empowered the developers with creating their own estimates. So we have taken 21:32 to get to how estimating can work. OK

22:35 – “Managers just manage schedule” – Great managers and leaders spend less than 10% of their time managing a schedule. The vast majority is working issues and helping to remove roadblocks for the team. Again the concept of manager is the Waterfall manager instead of the Agile Servant Leader manager.

23:25 – Never mind previous point. 🙂

24:27 – “Waste is whatever does not put valuable Software into the client’s hands” – Allen changes the definition of waste here to suit his point. Waste is whatever doesn’t provide value, not valuable software. Estimates may still provide value to the client even if it doesn’t create software.

25:48 – “estimates don’t help, because you don’t know you in trouble until later in the project” – Huh? If I have estimates I will get feedback very quickly on whether we are in trouble. Again, this seems to imply a waterfall approach where you are not running iterations that you learn from every week.

30:04 – “counting stories is enough, we don’t need to estimate” – Allen’s point is we only need to make two decisions. Either we kill the projects because the end date is too far out or we can add people. That assumes the only criteria is date. He ignores the fact that the cost of the project may need to be known to ensure it makes money for the company. Killing the project wastes money already spent, adding people increases the cost of the project. As usual, No Estimates is ignoring the need for budgetary decisions.

34:00 – “User Story Map is not a static document” – exactly like estimates. Both are not static documents and they change all the time. But it takes effort and expertise to manage that change.


As you can see, I disagree with much of the presentation. I align myself with the concepts and principles of No Inventory that you find in No Estimates. I believe that No Inventory is crucial to successful Agile Projects.

The No Commitment and No External Empathy part of No Estimates I patently don’t agree with. Can estimates have adverse effects? Absolutely. But we need to manage those and appreciate why estimates help others in the business and managerial roles. Software Development Projects are there to make the corporation more money. We need to be careful to balance what makes sense from a Software Development point of view with what makes sense from a business point of view.






Top three reasons why #NoEstimates is not a professional Software Development approach #Agile

In a recent post, I stated that some aspects of the #NoEstimates approach is not yet a professional Software Development approach. I believe it could become a professional Software Development approach, but it isn’t one yet. Some people raised an eyebrow to this statement and rightfully so. When you drop a bombshell like that you certainly should provide rationale and criteria as to how you ended up with that opinion.

Remember that this is also just my opinion, so do with it what you will. 🙂


Here we go!

1. The proposal and hypothesis should be clear, concise, and consistent

God help me, I really do have problem with knowing what #NoEstimates is proposing. Sometimes it is not doing any estimates – but do then again do them if you need to. Sometimes it is just working on a prioritized backlog and delivering in an incremental way delivering the highest priority items first. I find this ambiguity hurts the #NoEstimates cause more than it helps. If you believe in something, propose exactly what it is and stick to it. A lot of times we really don’t know what you are proposing that we should do. If you firmly  believe no one should do estimates, then say that and stick to it.

2. Don’t just criticize alternative theories

All the great ideas over time were able to stand up without criticizing alternative theories. Einstein never got on a soapbox and criticized Newtonian Physics. He simply proposed a new theory and illustrated why it described reality in a better way. The #NoEstimates proponents are actually hurting the acceptance by calling other methods ‘insane’ and ‘crazy’. It is almost the equivalent of swearing. Swearing is the easy way out of rationally describing your position to convince others of how it is a superior approach. To be clear, I don’t believe that a big-bang waterfall approach is better than Agile. But calling it ‘insane’ is intellectually lazy. I should be able to easily prove that to you. (and I can) Sometimes the discussions seem to resemble political attack ads more than anything else.

3. The facts should be available for peer review

Many times in discussions with #NoEstimates proponents I have seen opponents ask for the established companies that are using the extreme #NoEstimates processes of not estimating at all. Each time I usually get the response that they are soon going to interview them soon and would publish the results. I still haven’t seen any numbers published from companies that don’t estimate at all. So it is very difficult to validate the claims and whether the process would work in other situations.


In addition to these three characteristics, the inherent value of an approach is how wide the applicability is in the real world. If an approach is only viable in a controlled lab environment, then the approach is of not much use in the wild. For my money, an approach that is only applicable in a product company addressing only a very small share of the Software Development industry.

It probably is controversial, but the #NoEstimates movement has not yet demonstrated the widespread applicability in the Software Development Industry.

My Emotional #NoEstimates post

I’ve had multiple posts in the past where I’ve stated in very logical reasons why I believe in estimates. I’ve been thinking of penning an emotional #NoEstimates post lately. This is it.


Recently a close family member underwent major abdominal surgery. As the surgeon said, all abdominal surgery is major. Things went exceptionally well due to the world-class surgeon and tough patient.

But there were two aspects of the event that were very interesting to me from a Software Development point of view:


Yep, the surgeon provided estimates. Not just to me, but to everyone participating in the operation. You see, he was using a lot of shared resources that need to be co-ordinated across multiple surgeons and departments. You can’t just operate and then try to plan the next surgery after it is complete. There would be too much down time with critical health care resources. So all the procedures are estimated and scheduled on a priority basis to make the best use of scarce resources.


The surgeon’s report was the other eye-opening experience. For all your Software Development professionals that think no other industry is as complicated at Software Development and therefore it is difficult to estimate, I recommend reading a surgeon’s report.

Every minute, there is a surgeon operating somewhere not knowing what he is going to find when he or she opens up a patient. And through their skill and tenacity they estimate the procedures and then do their work in the best interests of their patients no matter what the original estimate was. Just like in Software Development, it isn’t acceptable to not provide an estimate on the procedure. I’m not sure we would have chosen the surgeon if he stated he didn’t know how long the surgery would have taken.

The Emotional #NoEstimates part

We as Software Development professionals need to get over ourselves and lack of professionalism in thinking our industry is unique and we shouldn’t need to provide estimates. Do estimates have negative aspects? Yes, but it is our duty to handle those negative aspects and work with estimates. We need to be brave to offer our commitment and then work with our teams when those commitments may not be able to be met.

When were discussing the surgery, it was dicey as to if it could be done at all. The surgeon looked us in the eye, said that he was confident that he could be done and provided an estimate about the procedure and recovery. From that point on we were one team focused on the procedure and recovery. And when the surgery or recovery went longer we discussed the reasons together.

If we as Software Development professionals don’t provide estimates, I don’t believe we are being true teammates with clients. We are asking more from them than we are willing to give.

For it to be a true #NoEstimates partnership, we don’t need to provide estimates but would only get paid when a feature is implemented in production. If we don’t need to commit to the client, they should not need to commit to us until they want to buy the product. Equal risk for client and Software Developers…

Now how many #NoEstimates proponents would sign up for that?


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