I think there is an underlying misunderstanding on the part of people who think that agile projects cannot commit to fixed dates and budgets. Let’s face facts first: to manage a business, executives need to know key dates, and due to interdependencies with marketing campaigns, commitments to stock analysts, and tie-ins to other dependent projects, we need to sometimes carve those dates into stone. Similarly, executives need to manage the cash flow of a business. To do so, they need a pretty accurate forecast for how much cash your project is planning to spend every month. We cannot (or should not) change these realities – too many other processes rely on this data.

So, where does that leave our project? Well, if you build a release plan (something many agile teams forget to do) listing all of the planned iterations, along with the iteration start and end dates, you get a pretty good view of a high-level project schedule. You can even insert key milestone dates (like the dates your CFO mentioned to the stock analysts) in this plan if required. Then, if you follow sound agile management practices, the high level plan should rarely change; if it does, it is usually just to add or delete iterations at the end of the release. Yes, the scope within those iterations may change a lot; however, with consistently-timeboxed iterations, you should not be messing with the overall plan.

You CAN make a firm commitment on dates to the executives, you’ll just vary the scope to accommodate the changes that arise during the project. Similarly, financial commitments can also be made with some degree of confidence.

To build that initial release plan, you’ll need to know your team size and the expected velocity for that team. If you know the daily (or hourly) cost rates for the resources on the team, it is a simple matter to multiply that by the number of days in your standard timeboxed iteration. The result is your burn rate per iteration. Multiply this by the number of iterations, and you get a good approximation of your final project budget.

The neat thing about using velocity as a forecasting tool, is that as your team’s velocity increases (perhaps due to increased efficiency due to process improvements or increases in skill levels as the team’s experience with the solution grows) the release plan recalibrates to show an earlier delivery date, and subsequently lower costs (or you could use the savings to incorporate more scope into the final solution). If the velocity degrades over time, the plan immediately recalibrates to show a later delivery date and higher costs, unless scope is dropped to maintain the original plan. If your goal is to keep to a firm cost commitment, then all you do is vary the scope as velocity changes, and you should find that your costs come in very close to what you had forecast.