How About #NoEstimates?

Let’s get this out of the way from the very onset.  I don’t believe estimates (and estimation) are evil and should NEVER be used.  Now that we have that out of the way, let me share estimation stories about two product teams.

Product Development – Commercial

There was a software development team that did annual releases of their software product. The team size was fixed as management realized that it was hard to have more than a certain number of people working on the same codebase at the same time.  Every year they’d spend a couple of weeks estimating items that were to make up the release.  They would decompose big items into smaller items that they thought were easier to estimate.  They would estimate by assigning hour ranges to the items assuming a sustainable development pace i.e. an individual working 35 or so hours a week. The estimators were experts in both the domain and the technology.  These estimates became a commitment of sorts because the plan(s)  for the year that went to upper management were based on the estimate they provided.  In spite of experience of the team, they would always find themselves scrambling at the end of the year, working at an unsustainable pace and having uncomfortable discussions on what needed to be cut.  After a while, the concluded that was just how software development worked.

Product Development – Internal Use

There was an internal IT software development team building a product to support a new service that the company would be providing.  Even though business leaders had a “general idea” of what the product needed to do, there was uncertainty as to exact pieces of functionality that needed to be provided and the order that these features would need to be provided in.  In other words, the “requirements” were fluid because everyone was still learning about the new service that was being offered.  The organization determined how big the team size would be based on a set budget and then set the team off the work.  For two years, this team worked without estimates, rather they would identify the work item of highest priority (note that these were the smallest slices of functionality that provided value) and would focus as many people they could (swarm) to complete the item as quickly as was possible.  When the organization decided that more needed to be delivered, more individuals were added to the team.  Over time, the team learned that in the worst case, in 6 weeks an item of value could be delivered.  At a certain point, there was a change in leadership and the new management team wanted the development team to provide single point estimates for a long (pages) feature list to which the team obliged.  This new management was uncomfortable with single point estimates returned and that led to a lot of back and forth with the development team until the team decided to give management what they wanted to hear/see.  As the saying goes “nine women cannot have a baby in one month”, and the team members told themselves that it was going to take whatever it would take regardless of whatever numbers they had provided. 

I realize that these two scenarios do not capture every product development scenario under the sun but that’s not the point.  The question in my opinion is this: Is estimation required all the time?  Should we just provide an estimate every time we’re asked to do so?  Some would say yes, but I beg to differ.  The act of estimation should provide value, in many cases, significant value.  If it isn’t, it’s most likely a waste of time and cause of much (unnecessary) pain.  It’s been suggested that professionals just provide estimates.  I disagree.  Professionals create/provide value and if an activity is a non-value add then it should be okay to have a discussion about the necessity of that activity.

 In the first story, we see that the team, estimated all the time.  But did they really need to?  Both cost (team size) and schedule (yearly releases) were practically fixed and they knew the items of highest value that had to make the release.  Could they have operated without estimating at all?  I’d venture to say yes.

Then there is the question of when something will be done.  Well, as we see in the second story, if we get into the practice of delivering working software in regular and frequent intervals, we can actually predict more effectively yet differently.  The team in story two was able to predict that in the worst case, after six weeks, they would deliver something of business value.  Note however that they did not predict when ALL the business value would be delivered as that’s a different game entirely.

There are those who believe that cost and schedule must be determined upfront at all times via estimates.  Is this true?  Are there not situations where cost and schedule are pre-determined via other methods as identified in the stories?  Isn’t it a concern if decision making is solely driven off of estimates?  It may surprise you to find out that this is very often the case in software development shops because its the easy (lazy) thing to do.  This results in teams often working on the shortest job with the least amount of value.

If we estimate, it’s because we need this information as an additional input into our decision making process.  The estimate must be of value and the more valuable the estimate needs to be, the better our estimation approach needs to be.  However, this requires that we’ve already estimated the value of the initiative we are undertaking ( when we have no estimate of the value of initiative, why are we estimating how long it will take or how long it will cost?  Of what value is the estimate in that particular scenario?)  and are trying answer questions such as the following:

  • Is the effort required to create something worth it?
  • Will the job complete on time for us to realize the value we estimated on it?
  • Which job should I start since I have two jobs of the same value?

If you believe that in your situation you need to answer the questions mentioned above, then I’d suggest the following:

  1. Read a good estimation book like How To Measure Anything before you start
  2. Use mature estimation techniques like Monte Carlo
  3. Gather a decent understanding of variation and how it applies in  your context
  4. Realize the output of mature estimation techniques is the probability of a set of different outcomes
  5. Plan based on the set of outcomes (and not just one outcome)

This applies to those asking (managers) for estimates and to those providing (development teams) estimates. Unfortunately many senior managers (vice-presidents, general managers, C-level execs etc etc) that I’ve come in contact with are not as educated as they should be about estimating in knowledge work.  This is extremely unfortunate as a manager with a misunderstanding of estimation, is unfortunately a very dangerous manager.

It has been suggested that any estimation is better than no estimation.  Um, I don’t think so.   At least, that’s not my experience.  Estimation done poorly, improperly or recklessly is harmful as unrealistic commitments are often its product.  Stress and de-motivation and a shoddy product follow shortly thereafter as its by-products.  

Some of us have gotten very good at gaming estimates and as a result have convinced ourselves that we are good estimators i.e. we are always spot on .  But let’s be honest now.  How about the extra hours you made the team work by reminding them of the estimate?  If your estimate is correct, how come the team did not work at a sustainable pace throughout?  Why did you decide that certain features can be deferred to the next release?

If you are the business of doing projects (hard start/stop dates) then I can also understand how the idea of always estimating may be essential to you.  But if you are in the business of developing and growing a strategic product over decades, then I believe there are other approaches that can be leveraged.  After all, the decision about whether to build the product has already been made.

I respect the fact (and the people) that some (many probably) within my profession believe that we must always estimate but I simply disagree with them.  I would hope that they could respect my opinion as well.  I will suggest you take a look at your particular situation and determine if estimates are critical to being successful at what you do.  Conduct an experiment of working without estimates if its possible.  If estimates are crucial to your success, then I charge you to estimate responsibly and if they aren’t, well how about #noestimates?


6 Replies to “How About #NoEstimates?”

  1. Nice post,
    Monte Carlo is not an estimating technique. Monte Carlo is a simulation tool, using a probability distribution and the upper, most likely, and lower bounds of that distribution to generate a set of values that can be analyzed. For example if there is a work effort whose “most likely” duration is 46 work days, but the optimistic duration is 42 days and pessimistic duration is 54 days, and whose probability distribution is a Triangle (best used when there is no historical data), then a MCS can generate a number of “possible” outcomes. These can be used to build a Cummulative Density Function showing the confidence of completing “on or before” a specific date in the sample distribution.

    If we’re spending other peoples money, it is likely they are interested in “how much” and “when will you be done.” This is the role of estimating.

    There are many ways to make estimates software development. Google “software cost estimating” to come in contact with the popular ones.

    Our goal as project managers is to make sure those funding our projects are aware of how estimating works, why it works, and how to properly employ estimates.


    1. Thanks @galleman for reading. I think we will disagree on whether Monte Carlo can be used as an estimation technique. Sure there are many ways to estimate, I’ve never debated that. I just believe that because there are many ways to do a thing, it doesn’t mean it always has to be done. I think this where we see differently, and that’s ok.


  2. Hi Ebenezer. Enjoyed your post. I agree in that if the estimate provides no value, then don’t go through the exercise. I also agree that estimating is very very hard. Estimating budget is one thing; timeline is the harder of the two.


    1. Hi Rod. Long time. I think I can understand why timeline is considered to be harder (and maybe it is) but that may be in part because its harder to hide timelines overruns than it is to hide budget overruns.


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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