There may be a lot of questions your organization has regarding your agile project, but the most frequent one is probably „how much will this cost?“ This could be an issue about money, resources, or timing. In any case, budgeting for agile projects and sprint costs requires a different methodology compared to conventional project pricing and planning.
An article published in the Harvard Business Review revealed that 1 in 6 IT projects exceed 200% of their budget when considering initiatives worth millions of dollars. The root causes of this issue are two-fold: either the project’s actual cost is underestimated, or its costs are not tracked as they increase.
Delivering Cost Estimations
For your agile project or particular sprint, your company will want you to submit a cost estimate. Agile teams can struggle with cost projections since they are unclear of how precise and in-depth to make their estimates.
The development team may be distracted by traditional cost estimates, which can be quite time-consuming. You can finish your cost estimates in a number of ways.
Burn Rate Cost Approach
The first strategy is to work on the burn rate and duration of your sprint sessions. If the cost of each resource is known, it can be easy to calculate the true cost of the sprint session as there are a constant amount of time resource units. The strategy can be either of the following, depending on your available budget:
Average cost per person per hour: This is the easiest method because it just multiplies the number of hours each resource used throughout the sprint by the average cost that you were given. For example, with one full-time resource and one part-time resource costing $100 per hour (assuming eight hours per day), the cost of a two-week sprint would be (40 hours x $100) + (80 hours x $100), or $12,000 total.
Specific cost per person: In order to use this strategy, you would need to perform some additional calculations in order to determine each person’s hourly cost based on their annual compensation. The computation is the same as the average cost per hour once you’ve gotten down to an hourly rate.
Although this method of budgeting is simple, it has a significant drawback. It depends mostly on precisely determining the burn-down rate or grading each agile job. Before converting the sprint cost into a project or solution cost, the tasks must also have been estimated. This just addresses a portion of the issue.
Another problem is that it doesn’t account for extra expenses that arise outside of the sprint planning. To account for testing, administrative, meeting, and design hours, you will need to expand your costing model.
Precision-alignment approach
Another strategy involves a prioritized list of business outcomes and is more budget-oriented than estimation-oriented.
This real-world example is taken from a piece that Debbie Madden wrote for the Harvard Business Review. Assume for the moment that you are developing an online clothing store. This requirement can be broken into multiple areas that correspond to significant activities in the solution, such as:
- A marketing landing page
- A search function
- A feature for checkout
- Product web pages
- A database of customers
- Customer agent order management system
The next step is to calculate how long each task would take, using past performance as a guide or suggestions from developers:
| Task | Time | Budget |
| A marketing landing page | 2-4 weeks | $20k – $40k |
| A search function | 4 – 6 weeks | $40k – $60k |
| A feature for checkout | 6 – 8 weeks | $60k – $80k |
| Product web pages | 3 – 6 weeks | $30k – $60k |
| A database of customers | 2 – 4 weeks | $20k – $40k |
| Customer agent order management system | 4 – 8 weeks | $40k – $80k |
This leads to a budget range of $210,000–$360,000 for the first sweep. Despite this large range, the company is already able to decide if the minimal budget is significantly less than or more than the resources available for this project. If the range is too wide for the company, you can move on to the next phase.
Sort all of the jobs and give them a priority so that you can distinguish between „must haves“ and „optionals“:
| Task | Time | Budget | Priority |
| A marketing landing page | 2-4 weeks | $20k – $40k | 5 |
| A search function | 4 – 6 weeks | $40k – $60k | 3 |
| A feature for checkout | 6 – 8 weeks | $60k – $80k | 2 |
| Product web pages | 3 – 6 weeks | $30k – $60k | 1 |
| A database of customers | 2 – 4 weeks | $20k – $40k | 6 |
| Customer agent order management system | 4 – 8 weeks | $40k – $80k | 4 |
After allocating a priority, the business shows which items require a more precise cost estimate and discloses which items might be optional. In this fictional example, the budget has a narrower range since the top three priorities receive greater attention:
| Task | Time | Budget | Priority |
| A marketing landing page | 2-4 weeks | $20k – $40k | 5 |
| A search function | 4 – 6 weeks* | $40k – $60k | 3 |
| A feature for checkout | 6 – 8 weeks* | $60k – $80k | 2 |
| Product web pages | 3 – 6 weeks* | $30k – $60k | 1 |
| A database of customers | 2 – 4 weeks | $20k – $40k | 6 |
| Customer agent order management system | 4 – 8 weeks | $40k – $80k | 4 |
* shows the revised time estimation
The updated costs and revised timings offer a more manageable budget range of $230,000 to $330,000. This budgeting method takes less time and gives businesses the information they need to manage the project and decide whether to move forward.
Blend to your environment
Both strategies offer helpful budgeting information for an agile project, but they go in opposite directions. Depending on how you have applied the ideas of agile in your organization, you can blend parts of the two techniques. For example, the first method is perfect if you need to give mid-project sprint expenses and your agile ecosystem is well-developed. Given that the second strategy provides cost estimates at the appropriate stage of the project, it may be more appropriate if your environment is less developed and the project is in its early stages.
Conclusion
In conclusion, determining the cost of an agile project, particularly within the context of individual sprints, presents a unique challenge for organizations. Traditional cost estimation methods may prove time-consuming and lack precision, often resulting in unforeseen budget overruns. The burn rate cost approach could be suitable for well-established agile ecosystems requiring mid-project sprint expenses, whereas the precision-alignment approach may be more appropriate for less developed environments in the early stages of a project.
