Budgeting in Agile Software Development - How It’s Done?
Agile working is all about innovation, especially in software development. Innovation means change, often lots of it, including changes to your software project along the way. To manage that project, what’s needed are approaches that are both flexible and focused. And that includes your approach to budget management. Agile budgeting is a way of managing the investment in your project that responds to change – changing user requirements, changing business needs, changing circumstances. It’s budget management that can pivot with the project.
Table of contents
As an approach to software development, agile works because it acknowledges that the world is constantly changing, and if your app, website or digital platform is going to meet both user and business needs, the development of that product needs to be similarly flexible.
Waterfall vs agile budget management
From a budgeting perspective, this highlights a problem with how project budgets are traditionally managed. The ‘classic’ approach to budget management is top down (with a single, senior decision-maker), tightly controlled (with rigorous gatekeeping on expenditure), and is based on a detailed business case that decides on the appropriate level of investment at the beginning of the project (before any real development work has begun and often before the wider development are involved).
This is part and parcel of the waterfall approach to software development: you’re predicting (and restricting) your expenditure in advance. And that doesn’t work in a volatile, uncertain, complex and ambiguous world where you gain more knowledge, directing the final form of your digital product as the project proceeds. This is not to say that an agile budget isn’t planned in advance – it is – but that in a VUCA world, you need a way of managing that budget as you go, adapting to new information and relevant input as it becomes available.
How does agile budgeting work?
In agile, everything is both frequent and flexible – planning, reviews and retrospectives, communication, product iterations, etc. – and budget management should be no different. This means that once you plan something, you should be open to new circumstances. It doesn’t mean that it’s worth making changes to the initial assumptions just for the sake of it. But agile project budgeting does give you the luxury of pivoting depending on when the situation demands it.
An agile digital product development project works in sprint; short periods (1-2 weeks) dedicated to tackling prioritized activities from the project backlog with a view to producing an iteration of the product (a feature, a mechanism, a principle) for review, testing and feedback that will in turn influence the direction of the next sprint.
No surprise then, that agile budget management is also done in sprints or, more accurately, a cycle of flexible budget management is aligned to the project’s sprint timetable.
A basic agile budget planning process would be:
- Rough estimations based on customer’s requirements – This is an initial ballpark figure, the estimated cost for the project as a whole. It is based on information from the client or product owner about the expectations and requirements for the digital product: its target users, its purpose, what issue or problem it is intended to solve. This estimate is then further refined with more detailed information via a product discovery workshop.
- Product discovery workshop - This is an event that at Boldare, we use as the kick-off for every project. The idea is get the whole development team (including developers, quality assurance specialists, designers, etc.) together with a scrum master and, as the client’s representative, the product owner to really dig into the business idea and the details of the possible product so as to accurately identify the work required, and that includes budget considerations. In the product discovery workshop, the team discusses:
- The business idea and reason for the product.
- User stories.
- The state of the product’s maturity.
- Possible solutions.
- Technology choices.
- Project risks.
- Release planning – Based on the above information, the project team can now create the backlog of project activities to be carried out, including prioritizing those activities in light of user needs and business goals.
For the first sprint, priority activities are chosen and the specific budget for the sprint is calculated from the cost of the resources needed to deliver a successful sprint. For the overall project, a budget can be put together based on the size of the team, the number and length of the sprints required, any additional costs (including capital costs) plus 20-50% depending on the experience of the team and degree of certainty of the current information. Though, of course, this budget is subject to change as the project progresses.
- Delivering a product – Now, the sprints. Before each sprint the team has a sprint planning meeting. After every sprint, the team carries out a sprint review and a sprint retrospective. This planning and evaluation process includes checking and monitoring of the budget. Each sprint is fixed in terms of time. A dedicated development team has a fixed cost or rate in terms of human resources. This not only makes calculation of a sprint budget straightforward, it also makes it simple to see (and discuss) the budget implications of any changes, either to the product or the project’s priorities.
The beauty of the sprint planning and evaluation process is that the whole team is involved, including the scrum master and product owner. In other words, the team has all the input it needs to understand and plan for any pivots or changes in circumstance for the product, and can respond quickly (agilely!) to such changes as they arise.
Put simply, along with everything else about the project, agile budgeting and forecasting as well as expenditure is reviewed regularly and often, and adjusted when necessary to achieve the project’s goals.
The benefits of agile budgeting in scrum
The use of agile budget closely links your financial decisions to the circumstances of the project which, in turn, offers significant benefits:
- By budgeting in sprints, the task of budget management is tightly aligned to the structure and timetable of the project itself.
- Given that sprints are precisely defined periods of time, it is also easy to translate the project’s budget into quarterly or annual terms, for when you need to put it in the wider context of your organizational financial management.
- By only ever doing detailed budgeting a few weeks in advance, the process has a great deal of flexibility. Should any factor or circumstance change (for example, a viral pandemic means that your development team is now dispersed and all working from home) it will not affect the rest of the year’s budget. You simply recalibrate the project’s course or expenditure in the next round of reviews and retrospectives.
- The budget can be amended from one product iteration to another, based on real feedback – thus ensuring that the product (and project) is more user-focused.
- Agile budget management is distributed rather than invested in a single budget-holder, giving a broader perspective and greater input to the budget management process and, ideally, making it more effective.
Who are the agile budget managers?
Just to bust a myth, an agile budget must still be managed. It may be flexible but there are still accountabilities, and decisions to be taken. How to manage budget in agile projects and who does it? The answer is, potentially everyone.
The whole process of agile software development seeks to avoid obvious ‘manager’ roles. For example, a scrum master is not there to manage the team but to guide and facilitate the work it decides to tackle within the scrum framework. At Boldare, in our agile project teams, we have a scrum master, a product owner, and a development including coders, quality assurance, UX designers, etc. Everyone has input into budget management.
The product owner and scrum master estimate a budget for each activity or item on the project backlog. This estimation is based on the cost of the team’s time, a time estimate for each item, and any additional costs factored in. For each item, the whole team has discussed its details, including the best way to achieve or deliver the item plus the timing, scope and necessary quality.
For monitoring, the product owner has overall responsibility for defining the backlog and has access to budgeting information, such as the time spent so far on the project, and the remaining time needed. This information effectively gives the product owner a dashboard of up to date budget data, the most reliable basis possible for decisions about expenditure.
The key is, there is no single budget-holder. The responsibilities for budget management are distributed: the product owner manages the backlog, the product owner and scrum master agree the budget (based on the whole team discussion), and the team delivers the backlog and spends or manages the sprint budget within agreed constraints.
Agile budget management is essential
At Boldare, we stand by our belief that agile approaches are the best for digital product development and that includes agile budget management. The flexibility gained by linking budget management to the sprint cycle of a project ensures that expenditure can respond rapidly to changing circumstances and factors, including user feedback on product iterations. In a VUCA world, agility is essential for this kind of project and when you consider the alternative, agility depends on budget management – a fixed budget (waterfall style) would undo or prevent much of the project’s flexibility, undermining the wider benefits of an agile approach.
Share this article:
