Software Estimation is hard (right)?
Martin Woodward has a great article on software estimation, why it is hard and what Agile brings to the table. The approach I have seen the most in the past is the grand old FITA analysis (Finger in The Air) estimate. Get it right and your on time, get it wrong all hell breaks loose (most of which cost money e.g the cost of late delivery, the cost of extra development etc). If the coders finish early then chances are Parkinsons law applies and still costs you. Projects even fail completely or the customer walks away never to be seen again, software estimation should be science and not an art, but that's what it is.
If you have not read the Agile Planning and Estimation book then you should, much of what I am going to talk about here is distilled from Mike Cohns book and is an invaluable read.
Activity based planning (gantt chart) folds in several tasks into a single activity e.g
create new shopping basket
A block of time is then set for that activity, FITA 4 days. There are many things wrong with this, the customer won't see any progression in those steps e.g.
create visual layout for basket
create add functionality
create edit\delete functionality
create summary
If the customer sees progression they will be happy with what they are getting and most criticially by breaking down the task into features you can estimate better.
Let's rank these first by what the customer wants to see first from 1-5, the customer may rank them all at 5 but only 1 feature can be ranked high.
5 create visual layout for basket
4 mcreate add functionality
4 create edit\delete functionality
3 create summary
In the first pass we know what the customer wants to see right away "create visual layout for basket". Agile works in time blocks (called iterations) these provide a set block of time so that everything is not done all at once, the customer can see progress and can ask for changes but at the end of iteration, you set how long each one is but they are intended to be short, 1 week at best. For a given week therefore we know anything we do can be no longer than a week (if so it may need further breaking down).
For each feature we do a certain amount of FITA (or any other approach you like) but with it broken down we try to base it on work we have done before on previous projects or iterations. Again we score based on time,
7 days 1
6 days 2
5 days 3
4 days 4
3 days 5
2 days 6
1 days 7
which gives us
6 create visual layout for basket
7 mcreate add functionality
7 create edit\delete functionality
7 create summary
Which gives us 5 days in total, a day longer than our first FITA approach (you may be thinking why the task takes a day longer, if 4 days is inaccruate then either the developers will work 2 days in 1 day to meet that deadline or the 4 days you give the customer will turn into the actual 5 days it takes). If we match these up to what our customer wants to see we know what we will deliver to them in that iteration by adding up the scores.
11 create visual layout for basket
11 mcreate add functionality
11 create edit\delete functionality
10 create summary
In the 7 day block we can deliver to the customer with 2 days to go. If the iteration was shortend (assuming other feature planning allows) to 5 days then the we can still deliver. Let's assume that the customer wants to see something in 4 days (again assumming other features allow) then you could still deliver the features they rank as important but the lesser important features slip to the next iteration, if the customer wants that feature then either the iteration remains at 5 days or the feature moves to the next iteration (which could be shorter still).
Your still guessing time for functionality though?
Yes you are but by being broken down into smaller tasks you can far more easily base them on previous tasks that may be associated to the task in question. If your guess is wrong and the task takes longer or is completed faster then you can adjust the task for next time. Looping in members of the team also makes the difference here, Agile involves the whole team in the planning experience and you should draw on their experince for how long features may take, planning poker can also help here.
How do you estimate software timescales, what works for you?