Chapter 14: Budgeting for Agile Work – Everything you want to know about Agile


Most Agile initiatives will be constrained by a budget allocation that is identified at the start of the process. Whether or not the budget is realistic, this is the amount available for the Agile team to use. So, it is critical that the department endeavors to maximize the business value that can be delivered within this constraint.

The following presents two ideal models for managing funding for Agile work, and then identifies how departments can realistically manage their budgets when the flexibility of the Agile-specific funding model is not possible.

The ideal

In an ideal world, budget allocations for Agile work would be managed using one of two models:

1. Per iteration cost, or

2. Per units of work cost

both of which are directly aligned with the incremental planning approaches used in Agile work. Each of these models is described in the following sections.

Management by iteration cost

Management by iteration cost effectively means that the department manages each initiative by allocating a team of resources (with an associated cost) for as many iterations as can be funded within the available budget. The determination of what work is undertaken by the team in each iteration (i.e. what high-priority features are delivered) is left to the joint decision of the customer and the project team as part of the planning work for each iteration. Each iteration planning session also provides the opportunity (where needed) for the department to compare the business value of remaining work for that initiative against the cost of future iterations, in order to determine whether available resources could be more effectively assigned to other high-value activities in the department.

In order to calculate per iteration budgeting costs, you need to:

•   Determine the per iteration cost of the resources on the project team using the standard full-time equivalent (FTE) calculations in your organization for the two- to four-week period. This is the project team cost60

•   Identify any additional overhead costs that are known upfront, such as equipment that needs to be purchased or facilities that need to be acquired. This is the known overhead cost.

Then use the formula in Figure 5 to determine how much work can be achieved (the number of iterations remaining) within the allocated budget for that initiative:

Figure 5: Budgeting per iteration formula

The number of remaining iterations identifies the duration of future work that the team can commit to within the initially allocated available budget.

At each iteration planning session, the customer and the project team are in a position to revisit this calculation using the information available at that time, specifically:

•   The remaining available budget

•   Any additional known overhead costs (e.g. equipment that is now needed based on a newly identified requirement)

•   Any changes to resourcing levels in the team.

Running this same calculation at each iteration-planning session will allow the department to know how many more iterations are remaining within the available budget – and, most importantly, it will enable the customer to calculate the business value of the remaining work against that figure. This will help identify whether the value of proposed work aligns with the cost of subsequent iterations, which can help the department to determine the extent to which the initiative should continue.

From a budget-management perspective, this is the absolute simplest way to manage expended and ongoing costs for an Agile initiative. It does, however, require a level of trust in the Agile approach (and in the project team) to deliver business value without committing to a predetermined set of features for the allocated funds. Therefore, it is more likely to be applicable to Agile work with a longstanding customer.

Management by units of work

In situations where the department (or the customer) wants to directly correlate budget expenditure with the specific features of the solution that will be delivered within the allocated funding, the management by units of work model can be used to determine the budget dollars needed to support this work.

The “management by units of work” model assigns a number of units to each feature in the backlog item, based on the expected effort needed for the team to deliver that feature (e.g. one for simple features, five for complex features). The sum of all the assigned units of work across all of the features scheduled for an iteration, a release, or even the project overall, can then be combined with information on the team’s historical rate of delivery (i.e. their velocity) for equivalent projects to determine how long the project team will need to deliver the features.

In order to calculate “units of work” budgeting costs for an entire project, you need to:

•   Have the project team allocate a number of units to each item (i.e. feature) on the requirements backlog. This is the item effort.

•   Calculate the total item effort for all the backlog items that are scheduled to be delivered for the entire project. This is the project effort.

•   Use the team’s historical velocity to identify how many units (on average) they are able to deliver per iteration, noting that the work should be of an equivalent complexity61. This is the team delivery rate.

•   Determine the per iteration cost of the resources on the project team using the standard full-time equivalent (FTE) calculations in your organization for the two- to four-week period. This is the project team cost.

•   Identify any additional overhead costs that are known upfront, such as equipment that needs to be purchased or facilities that need to be acquired. This is the known overhead cost.

Then use the formula in Figure 6 to determine how much budget allocation is required to deliver the full scope of project work:

Figure 6: Budgeting per units of work formula

Using this model, you can also calculate the required budget allocation for all of the features in a planned iteration or release. This means that an equivalent approach to management by iteration cost can be used to estimate the cost of delivering the remaining items in the backlog at each iteration planning session – and to make subsequent decisions on the best overall use of the department’s resources.

As with all estimation work, using the team’s velocity to calculate productivity rates is not an exact science. Other unforeseen variables (e.g. sick leave) could impact the team’s future productivity levels – or the scheduled work may be more (or less) complex than was originally envisaged. It is, however, a way for you to know reasonably well where to “draw the line” on future backlog work, which will assist you in future budget planning.

The reality

Although budget management for Agile work is ideally structured using one of the models described in the previous section, the reality is that you are probably working with a fixed budget allocation that is tied to:

•   An immovable deadline, and/or

•   A pre-determined scope of work.

If you are planning to use Agile approaches to deliver these requirements, then you may need to retrofit your iterative work into these fixed constraints using a variation on the management by iteration cost model that was described in the previous section, as described below:

•   Determine how many iterations of work your staff can do by:

   Using the formula in Figure 5 to identify the number of remaining iterations within the available budget

   Using the immovable deadline to determine how many iterations can be completed in the available time.

•   Work with the customer to ensure that the items at the top of the backlog correspond to the pre-determined scope for this work (or that they actively agree to a variation on this scope).

There will, inevitably, be differences in the number of iterations of work for the remaining budget, the remaining time, and the remaining work to be completed. If there is more available budget than time, you can supplement the project team (or establish a second, concurrent team), so that more capability is delivered. However, if there is more available time than budget, you will need to put an end date on internal work, even if that date is before the agreed deadline.

The bottom line

Working within a fixed budget amount may mean that there are insufficient funds to achieve everything that the organization would like (as is generally the case with budget allocations). Unlike traditional software development methods, however, the very nature of Agile approaches can guarantee that the limited budget available will not be squandered on work that brings little value to the organization.


60 Note that some organizations also include the cost of the customer’s time for iteration planning and outcomes review work in these calculations.

61 Where the team is newly formed – or the budgeted work is significantly different from previous projects – you may need to estimate this number until the team has established a reliable velocity.