How do you estimate an agile project up front?
When working on fixed price software development projects, I frequently find myself having to estimate the total number of hours a project will take after the price is set, but before the work is started (or VERY early on in the development). Unfortunately, these types of projects are best developed using an iterative/agile method, which means that we don’t (and really can’t) do a complete up-front design.
In a typical scenario, we would have a contract that has X features and Y dollars. After contracting, the engineering department would then need to estimate the number of hours required to complete the X features. There are several possible reasons to need this information up front, including:
• The Y dollars translates to Z hours available, so we have to make sure that time(X)<=Z, perhaps by reducing the scope of X.
• The delivery date is set, and so we have to assign the appropriate resources to meet that date.
Kelly Waters has an interesting take on estimating agile here: http://www.agile-software-development.com/2009/04/agile-estimating.html Unfortunately, these are estimations of difficulty, using a points system, and do not translate to hours.
It seems to me that we need to be able to do one of two things:
• Obtain contracts that have a huge amount of flexibility in them to accommodate an agile development process.
• Figure out how to provide reasonably accurate up-front estimates for features that have not yet been designed.
The first option is of course not an option in most cases. Does anyone have any advice/guidance on how to generate up-front estimates in an agile development scenario?
Alternatively, does anyone see another option for solving our problem through some other process change?
Answer
I think every client wants to have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.
So, there are at least two documented ways you can do this and both are described in the "Agile Estimating and Planning" book by Mike Cohn that i strongly advise everyone to read.
Before your project even starts do the exercise of breaking down your stories in tasks and estimate each home in hours. Do the budget math with those estimates. Keep in mind that these estimates will only be used to reach the estimate time/budget. When the project starts the team should be responsible for estimating and creating the tasks like normal.
Use historical data. If the same team has worked before on a project with similar technology then you can use the past team velocity to estimate the project cost.
Again, for more details on how to do this read the referenced book.