For some time now within the software development community on Twitter, and by extension, some in the project management community, there has been an ongoing discussion surrounding a concept called No Estimates. Actually, the discussion (sometimes heated) has been around the hashtag #NoEstimates.

These discussions started out, as most discussions do, as an interaction between supposed professionals over a central concept, with both proponents and opponents, supporters and detractors. And like most conversations on the internet, it soon devolved into name calling, accusations of trolling, questioning of professionalism or qualifications, blocking of accounts, etc.

– I’m thinking of Godwins’ Law here – “As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches.”

Both sides (and yes, sadly it was divided into ‘sides’) quickly began digging in and defending their territory. An added component of this debate is that it included professionals from both the software development and project management realms, and as anyone who’s spent any time with both groups knows, there’s already a pre-existing animosity between the two groups. PM professionals tend to look at s/w devs as trying to skirt the more critical aspects of project management, and those on the s/w side look at PM’s as being too ‘controlling’ and not understanding the nuances and processes of development.

On the surface, this seems like a fairly straightforward issue… some are saying stop doing estimates, and some are saying they’re a necessary part of all projects.

Simple, right? Not so much.

After watching much back and forth, name calling, innuendo, insinuations, snark and sarcasm, I decided to try and see if I could make some sense of it all.

I put out a simple question on Twitter – “Q (sincere) for #NoEstimates proponents – what ‘problem’ is being solved? Products/results actually ‘better/more reliable’, or just faster?

As expected, I got some quick responses, most along the party lines of previous discussions. But to my surprise, I also received a note from Woody Zuill (@WoodyZuill), the creator of the #NoEstimates hashtag, offering to speak with me directly (no 140 character limit) on what his original concept of #NoEstimates was, and is. Not being a fool or wanting to waste an opportunity, I jumped at the chance and we quickly arranged a time to talk later that same day (I love the internet sometimes).

The following are my take-aways from that almost hour-long conversation (Woody, feel free to correct me anywhere I have misstated or misunderstood our conversation.)


Per Woody, the #NoEstimates concept came as a result of some projects that he was working on several years ago that involved some new developments in already challenged projects. Rather than develop an estimate that was going to largely be guesswork on his part or have a low confidence level, he and the project Owner agreed to proceed with the development without first building an estimate (this is key, so remember it for later).

Following the successful completion of the project, and what turned into a lengthly association (collaboration), Woody wrote several articles about his experiences in developing without estimating. He also posted the idea to Twitter, using the hashtag #NoEstimates. That’s where things started to go…. well, you can decide for yourself if they got better or worse.


The #NoEstimates hashtag was Woody’s attempt to begin a dialogue with other s/w devs that were seeing some the same things he was. It was a quick way to throw out an idea and get some feedback. The #NoEstimates hashtag is short, simple, and gets to the heart of the concept.

And it’s worked. Woody told me that since the #NoEstimates tag started he’s had 200+ Skype calls or in-person meetings to discuss the idea, with people on both sides of the discussion. So in that respect, he’s accomplished his goal, he’s started a conversation.

It also started a firestorm of sorts. Due to Twitters 140 character limitation it’s almost impossible to accurately convey and define something as abstract as a concept and not have it be misunderstood by some.

Several proponents have even agreed that the hashtag doesn’t adequately convey the idea, and helps lead to misunderstandings. But for better or worse it’s there, and it’s the central placeholder.


No. #NoEstimates does NOT mean don’t estimate. Unless it doesn’t make sense to.

But there’s the key – it’s not your decision as to whether it makes sense or not. The decision as to whether an estimate is needed, or adds value, or is necessary, or is useless, or is whatever is the Owners to make. The decision whether to estimate is one made together, with both sides (Owner and Dev) deciding that this is the correct path.

One of the primary points I got from Woody is that he believes that estimating does have it’s place. In areas where you’re looking at types of work that have been done, and that you have some historical or experimental basis and can provide an estimate then it makes sense. His primary point is that #NoEstimates applies to work in which you have no previous information or experience, or where there’s substantial uncertainty or risk that cannot be identified or quantified.

It is NOT simply because you don’t like estimates, don’t think they’re necessary, or aren’t very good at them. It is not about simply jumping into development because you’d rather do that than estimate the work.


No. And Yes.

As with most things project related, the answer depends on the context. What domain, what specifics, what constraints, what uses, and so on. Every project is unique, and so every answer to the same question will be unique to that specific project.

So, no, you can’t make informed decisions with without an estimate. To make an informed and qualified decision, you need to know how much will this cost, how long will it take, what resources do I need, and for how long, etc. Someone has to pay for the time to build, and they generally want an idea of how much it’s going to cost before they have to pay.

And Yes…

Unless, and this is a big unless, all parties involved in the decision have agreed to not providing an estimate as being the best course of action, That making decisions without an estimate, without an idea of time or cost or even scope is the right path to follow. Without that agreement, that buy-in, then no, you can’t make an informed, qualified decisions without an estimate. Because then it’s not informed or qualified, and more than likely its a one-sided or self-serving decision.


Of course it has. All ideas and concepts are co-opted, misconstrued, misstated and misrepresented. It’s the nature of ideas and concepts. No two people see things exactly the same, (or rarely).

And it’s no different for #NoEstimates. Woody has stated he had no agenda when he first suggested NoEstimates, aside from opening a dialogue with other like-minded devs who saw what they viewed as a problem, and to start talking about ways to fix it.

But others have come out in support of #NE, and been very clear that they DO have an agenda. The largest (most vocal?) segment comes from those who want to do away with estimates altogether (not a position Woody supports or has ever called for).

From what I gather, this is in large part because they see no value in estimates, or even more simply they don’t like doing them or think they’re stupid. Hardly a good enough reason to abolish estimates, but when you’re making unilateral decisions about whether something adds value or not, you usually do it from a self-serving perspective.

For me, those that are taking this position as just as much in error about what #NoEstimates really is as those who are completely against it because they think estimates are always necessary.


So what are the key take-aways from my conversation?

  • #NoEstimates is not one, single, specific concept. It is intended to be an entryway into a broader discussion.
  • There is no one, specific definition of #NoEstimates (consequently there are multiple interpretations, leading to misunderstandings).
  • #NoEstimates is NOT about eliminating estimates altogether.
  • Estimates still have their place in the #NoEstimates world. The idea though is to discover the intended use, and then gain agreement on whether an estimate is useful in that specific situation.
  • #NoEstimates is/was intended to apply to work where new paths are being walked, new ideas being discovered, and new technologies being tested.
  • It is NOT intended be applied to situation where there IS historical information or methods for estimating the work.
  • #NoEstimates is NOT about not estimating because a) you don’t like to, b) you don’t know how to, c) you don’t think it’s necessary.


Depends. Having spent the majority of my career on the Business Owner side of managing projects, I see and know the value of estimates, even fuzzy ones where things are not always clear. I think the act of building the estimate also helps work through the idea of process.

But after talking with Woody and getting a better understanding of the actual concept behind it, I’d have to say that I’m more in agreement with it (or at lest more accepting) than I originally was. Project Management has as many ways to manage projects as there are types of projects. I’ve always been of the belief that the smart PM takes and uses what’s appropriate and useful for their particular project.

And in truth, that’s what any good PM should be doing – exploring and searching for ways to help make their projects successful.

Originally posted at:
Trevor K. Nelson
Rational Project Management

Leave a Reply

Your email address will not be published. Required fields are marked *