Saturday, June 21, 2008

Why non-agile project effort estimation sucks

Let's start with a warm up exercise back from school.

We have 4 voltmeters as in the picture below.
What is the total voltage if the voltmeters read:
V1 = 1V, V2 = 1V, V3 = 2V and V4 = 3V ?

You say 7V? Yeah, sure, maybe in your high school physics class, but definitely not in engineering lab.
What I mean is of course margin of error during measurement (please excuse my poor vocabulary).
I haven't given the margin explicitly, so you should have used the industry standard 0.5 of the meter's unit (which obviously is 1V, as otherwise I would say 1.0V. You should have guessed that too, of course)

So the answer is 7V±2 : most probably 7, but maybe 5 or 9.

Lets come back to software engineering.

I have 4 tasks, I estimate the first will take me 1 day, second too, third 2 days and the last one 3 days.
High school student may say the whole project will take me 7 days. Engineering student knows it will be from 5 to 9.
But hey, we are experienced software developers, so we know that developer's estimate has at best 30% error margin. If we are product managers we know we should multiply the developer's estimate by 8.
We are not product managers, so lets assume 30% (rounding up to half days, because we all know what happens when developer finishes the task an hour before lunch)

Real task estimates: T1,2 = 1d±0.5, T3 = 2d±1, T4 = 3d±1
Project estimate (on Monday): 7d±3, which means somewhere between this Thursday and the following weekend (unless I catch a cold, realize that task 4 is much bigger then I thought or Christmas happens)

To make things more interesting, do you remember how to calculate error margin for division?
(Oh yes, I definitely have 4 developers to divide work among, that flue that Bob has caught from Charlie is definitely not long term)

What does it all have to do with agile project management?
Well, if you commit only to 2-week iterations, you can be no more then 2 weeks behind the schedule before the project manager starts noticing.
Compare that to 6 month tasks that are 80% done until the last day, when they begin to be 90% done for next 6 months.

Coming soon: why Auto adjust in JIRA's Log Work action sucks :-)


  1. Bold statements are catchy as a title, but if you find one counter-example you prove them wrong ;). Maybe you can comment on this estimation method, for me it's far from scrum or agile in general:

  2. @groszek: Au contraire - the method described in the mentioned is pretty much equivalent to agile estimation in "ideal days", only worse, as it estimates effort required for a completion of a task, and not of delivering of a useful feature. The "ideal days" btw, is a measure I find inferior to estimating in story points, as it introduces units of value where they do not belong, and ties size of a task to individual developer's velocity.

    Reading the article, it seems like Joel is trying hard to reinvent (in a quite complicated manner) what has already been invented quite a long time ago by Scrummers. Sorry Joel, don't waste your time reinventing the wheel, just read a good agile planning book (e.g. "Agile Estimating and Planning" by Mike Cohn).

  3. Agile estimating (using story points) is really the best way to estimate and track user stories (features) I've worked with. Just this post is not clear ;)
    I read both Mike Cohn's books and know what it is about - the post simply doesn't explain it clearly.

    Sorry Slawek :)

  4. @marcin: Reading a bit more of Joel you'll notice that his familiar with agile concepts. I think his a kind of a person who can't accept that "God does play dice", for example he still belives in big design up-front. Nevertheless I really enjoyed his "Strategy Letter" series of articles.

  5. @groszek: well, "God does play dice" - the sooner you accept it, the better. My take on this is that software engineering is not a manufacturing discipline, where you can predict everything with a high degree of confidence. Rather, it is an art, with high degree of uncertainty - and it is not the only type of engineering where this is the case - everywhere where creativity is the tool of the craft (architecture, industrial design), this statement applies.

    The way to go about planning your work in such conditions is play with probabilities and maximize chances of success given huge amounts of unknown. Agile planning gives you tools to do it, traditional planning does not

  6. @groszek: I wanted to give myself some time to write a thoughtful response and your comment is already overwhelmed by my agile-zealot colleagues ;-)

    @all: I've read (and admired) Joel's blog long before I've been infected by Agile methodologies, so for me he is the source of all the ideology.

    My idea was not to write a blog post about agile project estimation, because:
    a) the subject is already covered by circa 1324656 blog posts
    b) written by people smarter then me (joking of course :-P),
    c) who have given much more thought to the subject.

    What I wanted to point out is the fact that as engineers we are great at spotting voltmeter error margins, deadlocks in the code before they happen or performance bottlenecks in earliest design, but we fail to notice exactly the same problems with regard to people, teams, planning activities etc.

    "God plays dice" - he doesn't need to, he has deterministic chaos at his disposal ;-)

    Software engineering is not art, it's science. Like physics, with Planck constants, Shroedinger cats and Heisenberg principle (you cannot simultaneously know project's scope, budget and schedule).

  7. @Slawek - now that makes sense :) And more so I totally agree with you (although I forgot all that Heisenberg, Planck, etc. stuff).

    @all not believing - I have a very very simple task for you. Please estimate how long will UEFA Euro 2008 final match last (I'm not asking about the result)? This is very simple task - much simpler than estimating programming tasks - even if you are not a football fan.
    Go ahead - I'm waiting for your estimates :)

  8. EURO 2008 final - I think it's gonna take one evening, including post mortem analysis, provided that beer is already in the fridge ;-)

  9. Very accurate estimate - as a reward you can buy me a beer when we meet in July (or August) ;)

  10. I'm caught by this line:

    Coming soon: why Auto adjust in JIRA's Log Work action sucks :-)

    I have been using JIRA for the past 2 years and would like to hear from you about that.


    - yc

  11. No worries, I was just writing that post (starting with "you see - I cannot even estimate when I'm gonna post that follow up post" ;-) ) when I got distracted with urgent matters. Again.
    I promise to write today.