How do you estimate an agile project up front?

Question

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 1

you don't really estimate agile projects up front. You should use an agile contract to solve this problem :-)

Answer 2

you don't, that would go completely against the entire paradigm of agile. what you can do is set a date and then work torwards it in iterations/sprints and let the product owner(s) decided what is important to get done by that date. the entire premise behind agile methodologies is to do away with arbitrary deadlines and the death march that they become. SCRUM works, read about it and do what it says.

Answer 3

Fixed price in Agile gives you a number of iterations you can run for a given team size. The point of Agile is then to maximize the value you can get during these iterations. Agile is about scope management.

So, you actually shouldn't do upfront estimations. This would mean fixed scope which is the just the opposite of Agile or anti-Agile if you prefer.

Agile doesn't work like this, you need a new kind of contract, as pointed out in another answer. See for example 10 Agile Contracts and/or google.

Answer 4

I don't really know anything about agile, but I would consider only contracting a date per iteration. That is, When you write your contract, only commit to the first iteration, and only price for the first iteration. Worry about iterations 2, 3, 4 and 5 when you get to them.

Your client may not like this. They are free to go somewhere else if they do not.

Please don't take my advice.

Answer 5

I think every client wants to have 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.

Answer 6

You should use an agile contract to solve this problem :-)

Answer 7

If you estimate the backlog items in story points (which is discussed in the Kelly Waters article you link to) then the question becomes how many story points do you expect your team to deliver in a sprint. If your team has been working together before, then you should be able to take a guess at this (perhaps with upper and lower bounds to indicate a confidence range).

If the team haven't worked together before, then you can take a few well-understood stories and break them down into detailed tasks. This will give you a man-hours number and you can compare this against your story point estimates to try and predict your velocity. Again, a confidence range of upper and lower values is probably appropriate.

Let's suppose your user stories add up to 150 points, and you predict that your team can deliver 15-20 story points per month, then the work will take 7.5 - 10 months (through simple division).

The advantage of this approach is that you can measure the team's actual velocity, and compare it to the plan. Re-estimating you timelines should also be pretty easy, e.g. if you discover after a couple of sprints that the team's velocity is actually only 10 story points per month, then you can easily predict what your revised timelines will be.

Do bear in mind that team velocity does fluctuate for a number of reasons. It is typically lower at the start of a project when the team is still forming. Also the team is most likely concentrating on infrastructure concerns at this point rather than delivering functionality.

Answer 8

Instead of aiming for a contract for the "entire" project, you should create a contract that just runs for a month or two.

Set some very low goals, perhaps only two or three features.

Explain to the client this is a discovery phase of the project. Without this phase you cannot give them an estimate for the entire scope. It would be in no ones interest to give them an inaccurate estimate.

The client benefits in the following ways:

• Lower upfront cost (only a fraction of the total price). If things go tits up that's there is a limit on their financial exposure (sensible given that most software projects fail).
• Have working software within a couple of months that may immediately solve some of their problems
• Have working software to provoke thought/conversation about requirements
• Client will discover more about what they actually want
• Client gets to see how well you work. If they don't like it they can look elsewhere.