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.

Big Upfront Estimation is just Big Upfront Design with $$$ attached

You don t, that would go completely against the entire paradigm of agile.

Agile can be about Fixed Costs

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. In this way a Sprint of 1 or 2 weeks is a Fixed Cost the same way it would be in an Big Up Front Design would be, it is just a smaller fixed cost.

The entire premise behind agile methodologies is to do away with arbitrary deadlines and the death march that they become because change is not accounted for in the contracts and deadlines. SCRUM works, is a great starting point to build a methodology on, read about it and do what it says at least as a starting point.

Short Sprints with customer feedback and approvals

Give you a starting point to refine your future estimations upon, and helps you gain trust from the product owner and customer very quickly, because they see their most important concerns delivered in a very short amount of time.

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.

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 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.

"you don t, that would go completely against the entire paradigm of agile": I think this is quite incorrect. Agile is common sense based and nobody would invest in project if they had no idea how much it would roughly cost: they understand they may have to cut scope to meet deadlines or increase budget and/or extend deadlines to deliver the whole scope. On my company projects, we estimate projects by comparing their size and are also estimating epics using poker planning. Using the cone of uncertainty, and without trading off quality, we are about maximum 50% off on our estimates prior to starting the first sprint compared to the reality. And we will improve as we build up our Agile expertise (on accuracy and time to get first estimates). You can t expect marketing to sponsor projects for 3 sprints (so up to 3 months) to have an idea of how much it would cost.

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.