Budgeting in Agile

Although it seems a contradiction, in Scrum the high-level flexibility is based on fixed times and fixed resources, such as team and budget.

(Note: this text is for advanced Agile practitioners. Pre-reading of the Agile Manifesto and Scrum Guidelines is required)

There is a lot of debate around how the budget should be allocated when managing a project in Agile. This should not be surprising as neither the Agile Manifesto nor the Scrum guidelines cover this topic in detail. To help bring some clarity, I would like to share some ideas that can make the interpretation of the mentioned texts easier.

“Reaction to change” is one of the essential values in Agile. It is about how important flexibility is; the team must always be ready to react fast and adapt the solution quickly. But practising this value is not just about the attitude of our people. It is mainly about how the project is organized and how well we respect the framework.  And although it seems a contradiction, in Scrum that high-level flexibility is based on fixed times and fixed resources, such as team and budget.

This is not the case in other methodologies. For example, Dr Martin Barnes in 1969 used the “iron-triangle” model to represent the constraints of traditional project management and proposed the opposite idea: a fixed scope with variable time and resources to be used in Waterfall approaches. From this perspective, keeping the scope unchanged is so valuable that delivering over-time and/or over-budget is widely accepted. There are many examples around the world of large projects being delayed for years or running completely out of budget with the non-negotiable objective of delivering what was originally planned.

This is the situation Scrum can help to avoid by setting a flexible scope together with fixed time and fixed resources. Following this idea, the team delivers the best possible working solution based on a given time and available resources. With this approach, projects are on time and on budget by design. 

In Scrum, this flexible scope is materialized in the product backlog: a vivid, emergent list of what is needed to improve the product in order to create a better version of it. The customer’s feedback is used to refine and prioritize the backlog thus giving frequent opportunities for adaptation and reaction.

Regarding the fixed time, it is embedded in the sprint event: a time-boxed iteration of no more than one month with a fixed length over time. Furthermore, when referring to resources the Scrum guidelines are clear about teams: there are limits on the team size and a clear preference for stable groups, with many references that suggest that changing members will negatively impact productivity and capacity planning.

Although budget allocation is not mentioned anywhere in the texts, we must find a way to make it compatible with the Agile mindset and the Scrum framework. That is, using the assigned money to reduce risks and enable the iterative approach.

When the budget is variable, as is the case in Waterfall, you first define the scope and then estimate how many resources are needed to deliver. However, when dealing with a fixed budget, you first determine how much money you want to invest, and then the Agile team will, through different iterations, define what can, and should be delivered.

If the team has followed simplicity as a principle and a working solution is expected by the end of the iteration, technically speaking, the budget requirements are essentially the team’s salaries needed to cover the mentioned period. In Scrum terms this could be summed up as: you only need enough money to run the immediate next sprint.

As future iterations are not yet defined by the team and may not even occur if customers express no value, any extra budget injected into the project is, in fact, adding risk. The extra budget generates the wrong idea that several iterations will be run even if no value can be created or that a certain number of features will be developed only to justify the investment. The latter are well-known problems when startups raise too much capital.  

There is another crucial point to be highlighted involving risk and budget. In Waterfall, the whole funding is unblocked at the beginning of the project, typically at the end of the planning phase, precisely when risk is at its highest. Thoughtlessly, money is asked when the probability of losing everything is a most likely occurrence. In Agile, the feedback collected at the end of each iteration is the key to unlocking the budget for the next one. This way, while uncertainty remains high, investment is kept low.

Agile will make budgeting in waterfall obsolete when facing innovative projects. Who will be the manager willing to assume the risk of injecting large amounts of money in risky ideas when they can be validated with minor disbursements?.

You may still have a question about the variable scope. What will I get if the project is managed with a fixed time and a fixed budget? And the answer is: you will get what is possible within the allocated budget or the last iteration.