In an agile environment, not all requirements are known at the beginning of the project, which is dissimilar to standard waterfall project management where absolute scope and budgets are calculated upfront. In this series, we discuss how businesses can workshop, identify, and predict the cost of their agile projects.

Throughout the delivery of agile projects, there will be continuous improvements and new requirements. Not all expected requirements will be built or even worked upon, because early user feedback of delivered product tells us that the planned requirements won’t be necessary.

Here at AgileXperts, we run a series of comprehensive workshops and we conduct backlog refinement to create a Product Roadmap. We use the Product Roadmap to understand how long we think it will take to build the product we have in mind. The cost of running the team over the expected duration of the project becomes the budget for the project. Then we build the most viable product with the budget we have, considering there may be incremental changes to the scope as we go.

The likely result is that the cost and duration of the project change continually. By incorporating early user feedback, we build a product which delivers the best value to the customer in all possible ways. This means, we may not end up with the same product we planned to build, because user requirements might have been changed due to market conditions, competition, technology boost etc.

At the start, it is important to make an initial Roadmap and to define a budget. This will help the organisation to make informed decisions of where to prioritise limited resources. At AgileXperts, we encourage the following considerations:

Estimation guide

In agile project management, you want to estimate requirements without digging into the details as they are yet to be refined. When running in an agile delivery model, we come up with a cost of running the project per agile sprint (fixed duration) which is based purely on the number of resources multiplied by their pro-rata rates, and simply estimate how many sprints we believe it will take to deliver a valuable outcome. Then the budget for that project is the people multiplied by (*) the duration of the project. This budget tends to change in a few scenarios like adding a new resource into the team, or if the requirement involves a new tool for which licencing is required.

Below is an example to understand it in a broader perspective:

Assume, we have 5 resources in our squad and the plan is to have sprint lengths of 2 weeks.

Total cost per sprint - AU$ 56,480

Total number of sprints to build the Minimum Viable Product (MVP) - 6 sprints

Hence, the total budget of the project to build the MVP is 6*56480= AU$338,880

This budget, however, does not include below additional costs:

  • Any vendor engagement

  • Procurement

  • Set up cost

  • Travel

  • Workshops and Trainings

If the project requires any of the above activities or any additional services, the budget changes accordingly. We recommend estimating any recurring cost with respect to the sprint.

A contingency on top of the budget is recommended for agile projects to run extra sprints if required. We can use several different ways to quantify risks and then calculate contingency cost. Many project managers believe in simple approaches:

  • 15-20% of total project cost

  • Cost of 2-3 sprints

Ever heard of a Confidence Level?

We can use confidence levels to help estimate the contingency budgets. Estimated confidence levels help the sponsor or management to make informed decisions for the project.

A Confidence Level is a measure of how confident a project manager/ team are in the estimates. We will talk more about confidence intervals and levels, and how to calculate contingency funding in a future part of this blog series.