Agile projects call for agile budgeting. Contrary to what one might think, agilely budgeted projects seldom see cost overruns. There are specific ‘security features’ designed into agile budgeting. How is agile budgeting different from classic methods of financial resource allocation? What roles participate in agile budget management? How to get started with agile budgeting?
Traditional vs. agile budgeting
First, let’s take a look at how agile budgeting is different from classic budgeting.
|Traditional budgeting||Agile budgeting|
Could you utilize traditional budgeting in agile projects? Classic budgeting methods have the potential to undermine the benefits of the agile approach in project/product management. In particular, the flexibility would suffer. Consequently, traditional budgeting rarely marries agile projects.
However, one could speculate that certain characteristics of traditional budgeting, such as the ‘Funding is granted before work begins’ might be more compatible with agile projects, than others, such as ‘Tight budget control’.
Agile budgeting step by step
Once you are into agile budgeting, what is the exact workflow?
- Roughly estimate the budget based on what the client or business sponsor say.
- Refine the estimate during a product discovery workshop. Involve developers, engineers, QA, graphic designers. Apart from the budget, discuss the scope, technology, and risks. Estimate individual features or user stories from the backlog, using story points or time units.
- Set the budget:
- for the whole agile project, using the formula from table 1. Optionally, set the budget for one year, you are looking at a multiannual project. This method works better with bigger, well-established organizations, especially ones with the centralized, top-down allocation of funding.
- Start-ups can budget from sprint to sprint. They can begin with the budget for the 1st, 2nd, and 3rd sprint only – based on the sprints’ goals and resources needed.
- The agile budget gets updated later, based on the velocity of teams. Moreover, with agile budgets, it is acceptable to indicate a range of costs, rather than a specific amount.
- Monitor the budget during sprint planning, review, and retrospective sessions. Update the budget, if needed, at the turn of the Program Increment or Product iteration.
Table 1. The budget of an agile project
|Team||# of iterations||Cost per iteration||Total cost|
|Fixed costs, e.g. PMO, program manager||22||3,000||66,000|
The budget of the agile project amounts to 1,410,000 – 1,692,000 (range), the agile project manager could state.
The “# of iterations” column has its roots in the project scope or product backlog estimation. Once you know the velocity of teams (note that the velocity is team-specific; read more in Story points, hot or not?), you can calculate how many iterations your project needs to be completed. Unfortunately, you get to know the velocities of teams after several iterations and that’s where traditional, top-down budgeting clashes with agile projects. You would need to update the agile budget periodically, en route.
Note that in the above example some teams participate in a limited number of iterations. Also, some agile projects assume a maximum number of iterations a project could last, let’s say 22 in the example above, and for the sake of simplicity Teams 1, 2, and 3 could as well be budgeted for all 22 iterations.
Cost per iteration – begin with each team member, or role, costing you: daily rate ($) * allocated time on the project (50%, 100%, etc.) * the number of workdays per iteration.
For instance, Software engineer A = $1,000 * 100% * 10 = $10,000
Now add the cost of all the team’s roles, to get the cost of the team per sprint.
Additional costs & Best practices
Add additional costs at the project level, and not at the team level, for clarity (locate the ‘Additional costs’ row in table 1). In software projects, the following are common additional costs:
- outsourced configuration costs,
Optionally, split additional costs into several budget lines, one for hardware, one for software, and so on. Additional costs tend to be local and difficult to quantify at the project outbreak.
These are golden rules of agile budgeting:
- Contingency costs tend to be added at the rate of 10 to 50%.
- In some industries, such as in the software industry, it is a challenge to set a realistic budget, due to the nature of the business.
- However, it is easier to budget a software project in an agile manner than using the classic methodology, since the agile budget crystallizes during the project.
After a few iterations and updates, the agile budget tends to be credible. The sponsor could then, in case of a multifold budget escalation, even cancel the project, although it is more common to see one of the three scenarios:
- the project continues until the original budget runs out, in the hope of a Minimum Viable Product at least, then the project ends,
- the project gets descoped,
- funding increases.
Advantages of agile budgeting
Those who tried and tested the above procedure indicate the following pros of agile budgeting:
- It is easy to calculate quarterly or annual budgets by multiplying the cost of a sprint by the number of sprints. The equation turns out to be quite an accurate method, given the two pillars of Scrum: stable team configuration and fixed sprint length.
- The nature of a sprint (1 to 2 weeks) facilitates frequent reviews of the budget; feedback arrives quickly.
- With such a short-term perspective agile budgets show increased one-time-event proofness (pandemic, revolutionary technology, etc).
- High-quality budgeting. Even rough, preliminary budget estimations tend to be accurate due to several internal experts involved, each with their unique point of view.
- Agile budget escalation, cost overrun occurs rarely. Descoping is seen more frequently, with the original schedule obeyed. In the descoping scenario, it is important to keep the MVP definition of a product close at hand.
Roles in agile budgeting
Funding is granted differently, from organization to organization. The CFO or steering committee might grant funding, so the two are the most obvious roles involved in the agile budgeting process. The money might also come from the resources of a specific department.
On the other end of the agile budgeting process are the Product Owner, Scrum Master, and in fact, the entire team. They estimate user stories in the backlog using story points or time units. And, as we remember, agile budgeting is all about knowing the crucial ‘# of iterations’ number. Who can tell that number more accurately than Product Owner and Scrum Master? In fact, any role at the team level can participate in estimating. Developers, UX designers, and QAs collectively constitute the ‘fuse’ or ‘security layer’ of the agile budget, providing as realistic as possible # of iterations needed to deliver a portion of value to a customer.
Product Owner serves yet another role in ensuring the budget is feasible. Product Owner prioritizes deliverables in the backlog – sort of “keeps an eye” on the budget execution. Not all deliverables might make it to the market, but it is the Product Owner who decides which ones will before the budget runs out. For this kind of budget oversight, it is good to have an aggregating dashboard (time spent, story points burnt, remaining estimates), such as the Overview in BigPicture.
Agile budgeting is vague about to what extent the $ constraints must be evident to agile teams. Should the teams be aware of the overall budget for their agile project? Should agile backlog and sprint reports apply dollar values to stories and features under development? —In my experience, many organizations have developed their own in-house, hybrid approach to monetary constraints in agile – says Jerzy Sekula, Product Owner at BigPicture.