One thing that I get sick of is how people take an estimate, expect it to be accurate, feed it into a plan, and when the plan is (inevitably) proven wrong, blame the estimate. This is a fallacy from the era of Waterfall development, but it still lingers on in many Agile environments.
Here’s a scenario: take a team with 10 people in it. This means, in theory, you get 50 person-days a week of work out of the week.
A project comes along. It’s estimated that it will take about 1300 person-days, or about six months, to build, test, and implement all the various stages (naturally, as it’s an Agile project, there will be staged releases as well as incremental and iterative work). Great! Plug that into a project plan as a six-month project. Oh, and line up other things around it to make it important that it takes six months – no more, no less.
Except that’s a load of crap. Consider this: in Australia, it’s usual for every person to get 4 weeks of leave per year (which, on average, they take all of it eventually), and 2 weeks of sick leave per year (which, on average, they take about half). So, for that six month, or 26-week project, there will be, on average, 2.5 weeks added simply due to expected leave being taken. So that 26 week project should be expected to take 28.5 weeks – on average.
The real problem here is the amount of variation available. People may take no leave in the time of the project, or they may take more than they accrue (most places allow you to accrue up to 8 weeks of rec leave; then there is long service leave…). You can’t predict it at the start of the project, as people don’t have to give more than one month’s worth of notice. So all of a sudden, my project has gone from a simple 26 weeks to a complex 28.5 weeks, with a lower bound of 26 to an upper bound of about 42 weeks (every person starts with 8 weeks leave, uses it, uses the two weeks sick leave, uses the next two weeks gained when the project goes past New Years, and uses the rec leave accrued during the project). All from just one variable that is out of the control of the project planner. And all this assumes the estimate is accurate in the first place.
There are an amazing amount of variables, most with a large range, that need to be tracked for project planning. Expecting an estimate made several months earlier to be accurate is crazy – but people still do it.
Share this:
Software is too expensive to build cheaply.... 
There are two measures of time for project planning, one for counting man days, and one for predicting the completion date. In your example, the employees’ leave doesn’t affect the man day count, but it does affect the completion date. There are other, more subtle things that affect the man days count, like installing software, attending company meetings, cigarette breaks, discussions about reality TV shows, filling in timesheets, helping junior developers understand threading, coming to work with a hangover, powercuts and network outages, just having a bad day, replying to management emails, and so on.
Because of these things, my project manager banks on 4 days out of 5 being productive, which adds another 20% to the completion date. He includes holiday and sick days, and adds a contingency of 20% to the top, to cover optimistic estimates. This doesn’t affect the number of man days expected to complete the work, but it does move the completion date on to a more realistic target.
Simon, that’s my whole point… the revised target is more realistic (like the 28.5 week target listed above), but it’s not any more accurate. It’s a good planning number, but it does have to be acknowledged that it is likely to be wrong.
My bitch here isn’t so much the process, which is a good starting point, but that people take the number as gospel, get annoyed when it changes, and bitch when it’s not met.
The bit I particularly love is when you’re asked to give estimates on stuff that hasn’t been specced out completely or things that you’re at such a high level of abstraction that it’s almost impossible to know what really is required.
That and the thousand and one meetings that are mostly bullshit status meetings or conf calls that should just be two people emailing each other..
The only real way to cope with estimates like that is to take whatever you think, add a week, double it and then round up.. 🙂
Nath
You bring up an interesting point – I get frustrated by the same thing at my company.
For me – I had to flip the situation around. I work for a software company that has customers. Customers have expectations. The business side has to manage these expectations. How would I like the business side of my company to manage these expectations? More importantly – how does the Agile process fit into this environment? Since I’m assuming that if you work for a software company the ultimate goal is to sell software.
If I give the management team anything – estimation or not – that will be the date which I’ll have to work twice as hard to hit.
So I have a couple of choices.
– Give them a date by fudging the numbers – they’ll stop believing me and start making up their own dates
– I can give all the facts to the project manager and let him deal with it.
– I can work on my estimation and practice it so that when I give an estimate to the business side it is much more accurate but still taken as an estimate
If there are other ways to make the Agile process fit into the business process with the ultimate goal of selling software I’d love to hear from you.
One technique i’ve adopted (after some good advice) was too provide a ranged estimate and/or also provide a “degree of confidence” in the estimate. So task x will take between 2 and 4 ideal days (whatever you define that as). For particularly speculative estimation i’ve said “here are my estimates, I’m 80% happy with them”.
If faced with the question of “hey you said 4 days and it took 8, why?!?” I’ve replied, oh, so you didn’t want estimates, you wanted actuals?