Why agile is a perfect fit in a fast-changing world
Since the publication of the agile manifesto, this dynamic, fluid approach to developing software products has proven itself over and over again. It’s perfect for both startups and the largest corporations, as it allows for constant improvements and adjustments based on changing needs. Agile development also facilitates innovation, problem solving and out-of-the-box thinking. When user requirements or business needs shift, an agile team can respond immediately, reducing losses and maintaining project momentum. The strength of agile lies mainly in its capacity for real-time improvements based on close cooperation between the product owner and the development team.
How agile empowers business growth
According to McKinsey, agile transformation usually results in a 30% increase in efficiency, customer satisfaction, and employee engagement. Agile organizations work faster and are more innovative. On top of that, they outperform their competitors and are thrice as likely to become industry leaders. Spark, a telecom company from New Zealand, achieved a 70+ NPS and cut customer complaints by almost 40% thanks to agile transformation. Bearing Point provides similar data, citing a 30-75% faster time-to-market, 10-50% improved employee satisfaction, and 20-50% increase in productivity as the results of company agility.
Why agile can have a huge impact on your budget
What does the term “agile budgeting” imply? Just like agile development, it allows companies to prepare for sudden change, leaving their investments flexible enough to adjust if needed. In 2016, organizations wasted, on average, $97 million for every $1 billion invested in various projects. That is 9.7% of their investments – a huge amount. And this was already an improvement from the $122 million wasted in 2015. The positive change was very likely the result of many companies adopting new project management approaches, including agile.
How budgeting in agile software development works
It’s useful to look at agile budgeting in contrast to the more traditional waterfall approach. This classic method gives managers tight control over a project’s budget, as it’s usually decided on ahead of time, based on a detailed estimation provided by the development team. Because making changes to the budget on the go is difficult if not impossible, such an estimation likely includes a large safety margin, inflating the project’s overall cost and making it less likely to even begin.
Agile turns this approach on its head, as it’s based around frequent iterations and constant back-and-forth between the decision-makers and the development team. Project specifications are set up before work begins, but they are not set in stone. They can be easily adjusted in response to a sudden change on the market, for example. Additionally, agile teams work in sprints (usually 1-2 weeks long), during which they focus on delivering individual, working features. This allows them to present something that can be tested and judged by the product owner during the scheduled review meeting, which results in useful, immediate feedback.
Managing an agile budget matches the flow of the project, starting with a cost and time estimation prepared on the basis of client requirements. This gives the team and the client a reference point, and can be useful for the next step: workshopping project requirements. At this stage, technology and business consultants help the client refine their plan using effective methods, such as user stories or design thinking.
Next, it’s time to sort project tasks based on their release dates. For example, the client might want to start with a simple landing page to gather traction and create a waiting list, then follow up with an MVP version of the product. Once the MVP is live, some features will need to be added to it before others, to match users’ needs. Crucially, project teams often learn which features are most needed thanks to observing how users interact with the released software product. This means that assumptions made at the beginning of the project may be proven wrong, sometimes changing project scope and timeline.
Agile budgeting step by step
Agile projects require a type of bottom up, on the go budgeting managed by several decision makers and organized on a sprint-by-sprint basis. You can easily determine how much each sprint will cost. What might change along the way is the number of sprints needed, the composition of the development team, and client requirements.
It’s important to have people from various fields present during the product discovery workshop: software developers, a project manager, QA experts, designers, and possibly DevOps or marketing experts. They should consider the project’s scope, timeline and risks to plan the development of individual features from the backlog.
| Goal | Team composition | No. of sprints | Cost per sprint | Total cost |
| Feature 1 | PM, 2 engineers, QA | 5 | $10 | $50 |
| Feature 2 | PM, 2 engineers, QA, designer | 10 | $12 | $120 |
| Feature 3 | PM, 3 engineers, QA | 1 | $16 | $16 |
(The no. of sprints and cost per sprint used in the table are completely made up to simplify calculations.)
The example above is only one way to budget for an agile project. A lot will depend on your unique situation. Instead of budgeting by feature, you might use user stories, distinguish clear stages in the project based on team composition, or start with budgeting for the entire MVP.
Once that part of the estimation is ready, it’s good to consider additional costs, like licenses and hosting. Finally, it’s good practice to add a percentage on top as a contingency. The result may not hold up throughout the entire project, but once work begins and several iterations are completed, the budget can be updated based on real world data specific to the project.
Typical agile budgeting challenges
Your agile project’s initial budget cannot be seen as final. A number of unforeseen events may require changes to product requirements or timeline, which often impact development costs. Let’s take a look at some of them.
- Unexpected problems with integrations, particularly with legacy systems,
- Unavailability of critical team members, e.g. due to illness,
- Delays caused by third parties, such as hosting providers,
- The necessity to rework some features based on user feedback.
To protect your project from the effects of these and similar surprises, regular sprint reviews and feedback are instrumental. They will allow you and your team to spot upcoming challenges and adapt to them, for example by focusing on a different set of features while the original goal remains blocked by a third party. As a result, these challenges may have a very mild impact on your budget, if any.
Start with a product discovery or story mapping workshop
To understand your product better and make sure that it will answer users’ problems, get in touch with an agency like DEVTALENTS and start with a workshop. Our experts have experience with both product discovery (which allows us to gain deep understanding of the project) and story mapping (which results in a user story map that visualizes development goals). It’s often the most efficient way to begin, as it combines planning with sharing information about the project with the team. The results can be a great basis for preparing an agile project budget.
If you’d like to know more about this approach, or have a project you’d like to consult with us, let us know!
