Internal budgeting for agile software development

You're planning on building software at your organisation, and you’re not a software company.

Whether it's an app, API, data or DevOps, you want the best result and the best software – fast too, if possible – so you’ll deliver using a form of agile. Scope is flexible, and time is flexible (hopefully).

But budget is not. It's annual budgeting time, and finance needs a number. You’re in a traditional organisation, or government. How do you know how much to budget if you haven’t worked out exactly what you’re building yet?

Building is an investment

Spending money on building software is more like an investment rather than a procurement. The returns are unknown. It could be reasonable, or a bad investment, or it could shoot the lights out and be transformational for the business.

You don't know the real result ahead of time. You don't know all the areas it's going to impact. You also don't know the exact cost. This is separate and distinct to paying for software licenses, which are generally more like a standard procurement. As with many investments, it’s more difficult to estimate.

An aside: I'm of the opinion that while software development can be capitalised, and it can often be advantageous for your business to do that, depending on the accounting outcomes you want to achieve, software licensing should almost never be, even if it's perpetual. Yes, there are many ways to treat these accounting-wise. You don't own software licensing, you have a right to use. Aside over.

The sticking point

I find this can be a significant sticking point in many organisations that are getting into software development. It's time consuming - not to mention inaccurate - doing a detailed feature and cost estimate before your budget.

Software projects are notoriously difficult to estimate. You might not have the time (or budget) to even work out the full detail to determine the budget itself. If you spend too long trying to do so, you’ll cost time in execution and delay your strategy. And setting a firm budget this early can also cost you later – you’ll set a budget for a 2-bedroom townhouse when you end up deciding to have four children later.

So how do you get past this sticking point?

There's a quick and easy way I recommend when it comes to budgeting for software development, which hopefully takes some of the pain away. It’s imprecise, but it works.

A simple method

The fast, simple method I recommend when you don’t have the luxury of a detailed plan:

• Work out your agile team size – what you think is reasonable
• Determine a cost per sprint for that team
• Multiply by 22 or 23 two-week sprints per year, allowing time for sick time, leave and holidays
• That's your annual budget for the product you're building

That’s it. It's brute force and imprecise. But it saves a lot of time. There’s no feature planning or estimates. No scope. You do those later. If you want to build more? Increase the team size. Have less budget? Reduce team size or duration and accept you’ll develop less features.

It also requires accepting other tenets of modern software development - that estimation is hard, requirements change, and building working software for the use case is more important than building to a spec. All which results in better software.

Thoughts or opinions - I'd love to hear them.