How to Budget for an Agile Software Development Project  

This article is a guide for product owners on how to set a budget for an Agile software development project. Agile delivery methods are proven to provide a better software market/people fit. A truly agile project dictates that the budget, in this case time of effort is only realised in hindsight. This is contrary to how businesses and cashflow works. We're yet to find a finance officer who is willing to give carte blanche, especially when it comes to software development. Quite rightly so. This leaves the product requirements owner between a rock and a hard space. Do you multiply the best case by a factor of three, or five...or your worst case...It's a dark art. Often the product owner is left in the middle between the business expectations and trying to ensure the project doesn't overrun. This article won't provide all the answers but we would like to share our learnings. 

These learnings come from running a software development services agency in Brisbane. We've grown from 8 employees, to 66 in four years. Along the way we've had to adapt from our mistakes and ensure they're never repeated. The documentation of these learnings has led to the creation of our Way of Working. 

Here's an overview of our learnings: 

Understand where an advantage can be won: Behaviour Field Trials. 

Agree to project success trade offs: Fixed Scope, Variable Time. 

Use a scientific risk based estimation method to approximate effort required. 

Take Advantage of Technology

The first is to leverage technology to your advantage. For us, that's the Codebots technology set. A software development platform as a service that writes on average 92% of a target application. It's bots that code. The way they do this is by writing 100% developer readable code based on models. They include the Entity Model (similar to a relational database model), User Interface Model and the Security Model. The Codebots have been trained to write Behaviours from these models that can be applied across any domain and are frequently used in software development. Think...Dashboard, timelines, forms, API's etc. 

For us to understand how the Codebots advantage can apply to the project we do something called a behaviour field trial. This is achieved by breaking the requirements of the new application into segments. This can be done from a backlog, an old legacy app or just general documentation. For this example, we have used this prototype of a bike sharing app. 

Once we have the segments we can link them to Codebots behaviours. Behaviours that already exist that can be applied to the project. These can be either fully covered, partially covered or not covered at all. Here's an example of the sheet I used for the bike sharing app. 

As you can see from the above image. Codebots is going to give us 81.9% coverage of the segments. 45.5% is fully covered and 36.4% is partially covered requiring more customisation. Now we know what technology can help us, it's time to talk about project success. 

In 2024, based on recent insights from Codebots, their platform can provide substantial coverage of application segments, significantly streamlining the software development process. By automating the coding of various components, Codebots can handle the bulk of application development tasks, reducing the need for custom code. Once the technology’s potential is understood, the next step is to focus on setting up the project for success by determining the best approach to managing scope and time. 

Project Trade Offs

This is simple to comprehend but easily ignored and very clear in hindsight if you've ever been involved in a software project. It's called project success sliders. Essentially, there are three options: quality, time and scope. We never vary quality but we can vary time and scope between fixed and variable. 

 

As you can see from the above image this gives your three options: 

Fixed Time, Fixed Scope = High Risk 

Fixed Time, Variable Scope = Low Risk 

Variable Time, Fixed Scope = Medium Risk 

We recommend fixed time and variable scope. The reason for this is that you can fix the time to a budget you're comfortable with and always add more if required. Varying the scope means being willing to trade off on time to achieve the best outcome for the end user and business. This is the hardest concept for a product owner and where their focus should be directed. Prioritising what is most important and most valuable to users, not worrying about project overrun is the mindset that every project manager should be in. It isn't easy! 

Estimations 

Okay, so we know the tech and we agree on a success approach, let's get into the estimations! For the sake of your time I am not going to fully explain our estimation process, you can check the spreadsheet for the bike app here. 

Here's a dot point summary of how we do it. 

Gather your estimators: web developer, tools tester & UX designer (kick the account manager out). 

Open the spreadsheet and list all the requirements scoped out in the project backlog. 

Approach every requirement individually and have each team member write their estimated time to complete the ticket. 

Our time scale rises in a fibonacci-esq sequence from 1 hour to 6 months in 11 increments. 

Score the complexity of the requirement with the teams familiarity with implementation on a scale of 1 to 5. 1 being easy and 5 being very difficult. This provides a risk factor which is applied to the project. 

The teams average time is multiplied by the risk factor to achieve the estimations. [Time with risk = estimated time * (1 + ((unfamiliarity * complexity) /25))] 

You now have your base estimations. We then multiply that time by 25% to account for raising the quality of the code base (we call this time the tail). We also provide a budget for Tech Spikes at 10% which can be used by the team to de-risk requirements before they go into developing them. This stops time blow outs. 

You now have your estimations. See the image below for how they worked out with the bike sharing app. 

 

In summary, the results are as follows; 

Approximate effort = 8.1 weeks 

Success trade offs: fixed time, variable scope = low risk 

Behaviour field trials = 45.5% fully covered, 34.6% partially covered, 18.6% custom code. 

Our recommendation would be to put a project team on the project for 8 weeks. Once you have the teams weekly rates you can multiply this by 8.1. 

If you have a project you'd like to commence this process with then let us know, we'll work through the steps above to get to an estimate.