Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Is ‘No Estimates’ for real?


No Estimates is a concept that I had not come across until very recently. The basic premise of No Estimates is there is significant inaccuracy in software development estimates. Even when you spend a lot of time estimating, it is still not necessarily accurate enough to give you an exact picture. Therefore, the time spent estimating does not give you a reward for that effort. Proponents of No Estimates argue you may as well spend that time and effort into understanding what the most important feature is to the user and concentrate on getting that delivered well. Once delivered, you concentrate on the next most import feature and so on.

Is No Estimation for real

When I first read about it, my initial reaction was it was like throwing the baby out with the bath water. Just because we are not as accurate at estimating simply giving it up seemed like lunacy. On reflection however, I can see it being useful for in-house teams that are supporting a business application. There the organisation has already seen value in continuous improvement and has accepted the software developers as part of the package to deliver the business outcome. You can concentrate on small measurable improvements to the application as directed by business. The users in this case are well versed with the application and are able to explain the desired improvement. Interestingly enough, in my experience this type of development is comparatively easier to estimate than others.

I also had a thought that product development teams may be able to use this in some manner. The rationale was they have quite a bit of control in terms of what they can cut out of scope if something turns out to be more difficult than initially perceived. However, the tradeoffs they make are not necessarily linear. There is usually not comparison that you can unilaterally say is feature A versus feature B. Feature A may very well be more important, only if it is likely to  be no more than 20% more in cost. No Estimates as a concept is not well geared to help in this scenario.

Even in scenarios where No Estimate is a reasonable course, I see significant risk of what I call ‘design blinkers’ – only taking into account the immediate requirement(s), rather than an overall view to limit rework. Design blinkers happen in all form of software development. This is because you can only design for your known scope. By limiting your thinking horizon to the next most important feature, you are in effect likely to encourage less holistic design.

From the reading I’ve done so far, it appears there is a level of misunderstanding in what estimates are used for in projects. There are no perfect estimates – projects are by nature risky. You can only ever be expected to deliver estimates with complete accuracy early on. They should get progressively accurate as you go through the various phases of the project. Initial estimates to judge whether the client has the cost appetiate to even embark on the journey, then further refining to understand whether your organisation can execute the project safely with a level of profit. These estimates will be less accurate than your feature level estimates, that you will be building up when the project goes into execution. In most cases you use multiple methods of estimating than simply a combination of all the features – previous track record, comparative scale with other similar projects and some level of feature based estimation.

In my view there will be very few situations where you can get away with doing no estimates and be able to make the decisions you or your customer needs to make. The answer is not to avoid estimating, but estimate at the level of accuracy that is required to make the decisions. Never estimate $X or hours Y. Always clearly state estimates with their level of accuracy i.e., $A to B or hours Y to Z.

Image Credit: Dilbert (Scott Adams)

4 responses to “Is ‘No Estimates’ for real?

  1. Ian Webster June 8, 2013 at 9:57 pm

    Nice post. As you say, it could work for internal development teams where there are few competing projects and a relatively large number of free developers to undertake potentially open ended projects. I obviously would work where there is a proper commercial relationship between the development team and the business.

  2. Philo June 9, 2013 at 3:31 pm

    It won’t even work for internal projects:

    “We need a new reporting module.”
    “Okay – we’ll deliver it as soon as it’s ready”
    [time passes]
    “Where’s that reporting module? It’s been three months!”
    “We’re not done yet – the whole team is dedicated to it – still going to take a while.”
    “We’ve got a dozen change requests backed up that need doing. I never would have requested the reporting module if I’d known it was going to take this long – it wasn’t that important.”

    Stakeholders will always have a vested interest in understanding level of effort necessary for changes, even if it’s only an order of magnitude ballpark. I agree that “no estimates” is baby/bathwater operation. And I’ll be interested to see how they run a business telling paying customers they’ll get an invoice when it’s all done, whenever.

  3. Joe Harris June 11, 2013 at 1:52 am

    Can I humbly suggest you read “Estimation Is Evil”? http://pragprog.com/magazines/2013-02/estimation-is-evil

    ‘Take the most important ideas, build them quickly, get them out there. Yes, it’s hard to do. That’s why it’s best. Stop estimating. Start shipping.’

    There’s a saying that ‘organisations perpetuate the problem they exists to solve.’ Project management, as widely practiced (PRINCE, etc.), perpetuates complex over-specified projects that require project managers.

    • Shoaib Ahmed June 11, 2013 at 7:08 am

      Thanks for the comment Joe. I have no issues with the principles. Even ignoring the relative merits of project methodologies, I have never come across scenarios where you can define the need for features on their own. Decision always hinges on the likely benefits for the investment. If you don’t know what investment you need to make to get a benefit, you cannot judge if it is a sound judgement.

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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 713 other followers

%d bloggers like this: