How to Budget for an Agile Software Development Project

This ar­ti­cle is a guide for prod­uct own­ers on how to set a bud­get for an Agile soft­ware de­vel­op­ment pro­ject. Agile de­liv­ery meth­ods are proven to pro­vide a bet­ter soft­ware mar­ket/​peo­ple fit. A truly ag­ile pro­ject dic­tates that the bud­get, in this case time of ef­fort is only re­alised in hind­sight. This is con­trary to how busi­nesses and cash­flow works. We’re yet to find a fi­nance of­fi­cer who is will­ing to give carte blanche, es­pe­cially when it comes to soft­ware de­vel­op­ment. Quite rightly so.

This leaves the prod­uct re­quire­ments owner be­tween a rock and a hard space. Do you mul­ti­ply the best case by a fac­tor of three, or five…or your worst case…It’s a dark art. Often the prod­uct owner is left in the mid­dle be­tween the busi­ness ex­pec­ta­tions and try­ing to en­sure the pro­ject does­n’t over­run. This ar­ti­cle won’t pro­vide all the an­swers but we would like to share our learn­ings.

These learn­ings come from run­ning a soft­ware de­vel­op­ment ser­vices agency in Brisbane. We’ve grown from 8 em­ploy­ees, to 66 in four years. Along the way we’ve had to adapt from our mis­takes and en­sure they’re never re­peated. The doc­u­men­ta­tion of these learn­ings has led to the cre­ation of our Way of Working.

Here’s an overview of our learn­ings:

  1. Understand where an ad­van­tage can be won: Behaviour Field Trials.
  2. Agree to pro­ject suc­cess trade offs: Fixed Scope, Variable Time.
  3. Use a sci­en­tific risk based es­ti­ma­tion method to ap­prox­i­mate ef­fort re­quired.

Take Advantage of Technology

The first is to lever­age tech­nol­ogy to your ad­van­tage. For us, that’s the Codebots tech­nol­ogy set. A soft­ware de­vel­op­ment plat­form as a ser­vice that writes on av­er­age 92% of a tar­get ap­pli­ca­tion. It’s bots that code. The way they do this is by writ­ing 100% de­vel­oper read­able code based on mod­els. They in­clude the Entity Model (similar to a re­la­tional data­base model), User Interface Model and the Security Model. The Codebots have been trained to write Behaviours from these mod­els that can be ap­plied across any do­main and are fre­quently used in soft­ware de­vel­op­ment. Think…Dashboard, time­lines, forms, APIs etc.

For us to un­der­stand how the Codebots ad­van­tage can ap­ply to the pro­ject we do some­thing called a be­hav­iour field trial. This is achieved by break­ing the re­quire­ments of the new ap­pli­ca­tion into seg­ments. This can be done from a back­log, an old legacy app or just gen­eral doc­u­men­ta­tion. For this ex­am­ple, we have used this pro­to­type of a bike shar­ing app.

Once we have the seg­ments we can link them to Codebots be­hav­iours. Behaviours that al­ready ex­ist that can be ap­plied to the pro­ject. These can be ei­ther fully cov­ered, par­tially cov­ered or not cov­ered at all. Here’s an ex­am­ple of the sheet I used for the bike shar­ing app.


As you can see from the above im­age. Codebots is go­ing to give us 81.9% cov­er­age of the seg­ments. 45.5% is fully cov­ered and 36.4% is par­tially cov­ered re­quir­ing more cus­tomi­sa­tion. Now we know what tech­nol­ogy can help us, it’s time to talk about pro­ject suc­cess.

Project Trade Offs

This is sim­ple to com­pre­hend but eas­ily ig­nored and very clear in hind­sight if you’ve ever been in­volved in a soft­ware pro­ject. It’s called pro­ject suc­cess slid­ers. Essentially, there are three op­tions: qual­ity, time and scope. We never vary qual­ity but we can vary time and scope be­tween fixed and vari­able.


As you can see from the above im­age this gives your three op­tions:

  1. Fixed Time, Fixed Scope = High Risk
  2. Fixed Time, Variable Scope = Low Risk
  3. Variable Time, Fixed Scope = Medium Risk

We rec­om­mend fixed time and vari­able scope. The rea­son for this is that you can fix the time to a bud­get you’re com­fort­able with and al­ways add more if re­quired. Varying the scope means be­ing will­ing to trade off on time to achieve the best out­come for the end user and busi­ness. This is the hard­est con­cept for a prod­uct owner and where their fo­cus should be di­rected. Prioritising what is most im­por­tant and most valu­able to users, not wor­ry­ing about pro­ject over­run is the mind­set that every pro­ject man­ager should be in. It is­n’t easy!

For a full read on pro­ject suc­cess slide offs check out the Way of Working here.


Okay, so we know the tech and we agree on a suc­cess ap­proach, let’s get into the es­ti­ma­tions! For the sake of your time I am not go­ing to fully ex­plain our es­ti­ma­tion process, you can check the spread­sheet for the bike app here.

Here’s a dot point sum­mary of how we do it.

  • Gather your es­ti­ma­tors: web de­vel­oper, tools tester & UX de­signer (kick the ac­count man­ager out).
  • Open the spread­sheet and list all the re­quire­ments scoped out in the pro­ject back­log.
  • Approach every re­quire­ment in­di­vid­u­ally and have each team mem­ber write their es­ti­mated time to com­plete the ticket.
  • Our time scale rises in a fi­bonacci-esq se­quence from 1 hour to 6 months in 11 in­cre­ments.
  • Score the com­plex­ity of the re­quire­ment with the teams fa­mil­iar­ity with im­ple­men­ta­tion on a scale of 1 to 5. 1 be­ing easy and 5 be­ing very dif­fi­cult. This pro­vides a risk fac­tor which is ap­plied to the pro­ject.
  • The teams av­er­age time is mul­ti­plied by the risk fac­tor to achieve the es­ti­ma­tions. [Time with risk = es­ti­mated time * (1 + ((unfamiliarity * com­plex­ity) /25))]
  • You now have your base es­ti­ma­tions. We then mul­ti­ply that time by 25% to ac­count for rais­ing the qual­ity of the code base (we call this time the tail). We also pro­vide a bud­get for Tech Spikes at 10% which can be used by the team to de-risk re­quire­ments be­fore they go into de­vel­op­ing them. This stops time blow outs.

You now have your es­ti­ma­tions. See the im­age be­low for how they worked out with the bike shar­ing app.


In sum­mary, the re­sults are as fol­lows;

  1. Approximate ef­fort = 8.1 weeks
  2. Success trade offs: fixed time, vari­able scope = low risk
  3. Behaviour field tri­als = 45.5% fully cov­ered, 34.6% par­tially cov­ered, 18.6% cus­tom code.

Our rec­om­men­da­tion would be to put a pro­ject team on the pro­ject for 8 weeks. Once you have the teams weekly rates you can mul­ti­ply this by 8.1.

If you have a pro­ject you’d like to com­mence this process with then let us know, we’ll work through the steps above to get to an es­ti­mate.


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

What are the monthly op­er­a­tional ex­penses to bud­get for a soft­ware ap­pli­ca­tion pro­ject?

02 March 2020

The Process and Price of Software Releases

19 May 2020

What are soft­ware es­ti­ma­tions: tra­di­tional vs sci­en­tific es­ti­mates

28 July 2020

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call