Project Budgeting
Traditionally, project budgeting uses a waterfall approach, adjusting the previous year’s budget based upon the projected spending for the coming year.
The problem with this approach is accuracy, or lack thereof. It is difficult to estimate how much money will be spent so far in advance, and therefore planning cannot be carried out with any level of precision.
Agile budgeting however is very different. Once the project has begun, the team gain increasing knowledge, and, as such, budgeting as the project progresses makes much more sense.
Agile Budgeting
In Agile, projects are budgeted in sprints, which typically correlate with project time. Each Agile team has a set human resource cost, whether that is an hourly or fixed rate per team member, and will be the same for each sprint.
Sprints that are consistent in terms of length, hours and team members, allow an accurate prediction of how many sprints are needed to complete the project, and therefore how much the project will cost overall.
Of course, other costs will also need to be budgeted for, such as materials, software and other supplies. It is likely however that the costs of these items will already be known.
How to calculate a budget
For managers who are more familiar with the traditional method of calculating a project budget, switching to Agile, where the budget is planned only as far as the next sprint, can be challenging.
The following six steps show how to calculate an Agile project budget.
1. Identify and estimate the project requirements
The requirements of the project should be listed and estimated. This is where the product backlog and user stories will be created in a Scrum approach.
The project team are gathered to order the tasks involved in the project, this can only be done by the team that will be working on the project. The team assign scores to each item to represent the relative effort involved. It is important to remember that this estimation is not yet linked to a time-frame.
2. Determine velocity
Next, the team need to determine how long its sprint will be. Having a defined sprint length allows the team to identify how much work they can complete per sprint. They will look down the product backlog list and select which items they believe that they can accomplish in the first sprint. This is why it is important to only have the project team involved in planning, only they can decide how much work they can complete within a set time-frame.
Once the items are chosen, the points from the first step are added up. The total number of points in a sprint become the velocity; one of the most important metrics in calculating a budget.
For more details on Sprint Velocity take a look at Overview Sprint Velocity Planning.
3. Budget calculation
Velocity estimates how much work the team can complete during a sprint and is used in the budget calculation of the project as a whole.
The scores from each item in the product backlog should be totalled, before being divided by the velocity. This will give the total number of sprints required to complete the project, and the time budget for the team to deliver.
Monetary budget is calculated using the team’s burn rate; the time it takes to complete one sprint. To find the burn rate, each team member’s salary is divided by the number of weeks in a year (52) and then multiplied by the number of weeks in one individual sprint.
The burn rate per sprint is then multiplied by the number of sprints to determine the budget for the project team.
4. Add capital costs
Most projects don’t run on labour costs alone, there is likely to be additional costs involved for tangible items such as equipment, materials and tools, and, for larger projects, perhaps land, vehicles and infrastructure.
Agile stems from software development where labour costs make up the majority of the budget, and, as such, there are no specific guidelines for accounting for capital costs.
To identify capital costs, the team should be asked if they know of any large purchases that will be required to complete the project. “Large” is identified as any item with a cost similar to, or higher than the labour cost of a sprint.
If any costs are identified, then they should be added to the project budget.
5. Add pre and post sprint budgets
Despite Agile teams being cross-functional, it is not practical to have every single area of expertise covered in just one team.
Any work outside of the immediate team’s expertise is added to the sprint as either pre or post work. For example, a product may need to be reviewed by a lawyer, however it is unlikely that the project team will include a full-time lawyer.
Where work outside of the project team is needed, it is useful to draw up a value stream map which will show the proportion of time spent on each type of work within the project. When the work undertaken by the project team is removed, the work required from outside of the team will be left and an appropriate amount of budget can be allocated.
6. Apply a drag to the overall estimate
Despite best intentions, projects can run over budget. Typically, 20-50% is added depending on how experienced the project team is. If agile budgeting has been used previously then the team will understand their velocity and be much better as estimating costs.
On the other hand, if this method of budgeting is fairly new then there is likely to be a high degree of uncertainty, and so a higher buffer should be added.
It is becoming increasingly unfeasible to plan a whole project’s budget, often based on previous year’s figures, up front, particularly in fast moving markets, such as technology.
Using sprint budgeting will result in more accurate estimations as costs can be adjusted from sprint to sprint, depending on how the project is progressing and changing external factors.
