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.
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.
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!
Here’s a dot point summary of how we do it.
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.