Traditional Budgeting vs. Agile Budgeting

In February I went to the London Scrum Users Meetup at Skills Matter, the speaker was an Agile/Scrum enthusiast named Ken Rubin, his chosen topic of the night was Agile Budgeting, Planning and Cost Accounting. He spoke about what agile budgeting is and how it compares to the more traditional ways of budgeting.

 Traditional budgeting uses a more waterfall approach, it begins with the previous year's budget and adjusts it based on assumed spend for the year coming, but how can you estimate how much money you're going to spend a year in advance? You can't, not accurately. 

 You can learn from the year before and you may have an idea or plan of what projects you hope to have completed in the next 6-12 months but you can't plan with nearly enough precision to ensure your budget and cost accounting is correct. 

 Ken explained that if you are budgeting a year in advance, before any of your projects have begun, you have the worst possible knowledge you're ever going to have about that project, yet you have to predict exactly how much you're going to spend and when, some organisations even start planning their budget for the next financial year in Q3, how can you possibly know what's going to happen over a year in advance?

 Once the project is underway, with every subsequent day, you have more knowledge about the project so it makes sense to budget as you go along rather than develop a plan potentially 15 months in advance, Ken then went onto demonstrate how agile budgeting is different and the benefits of using this method compared to traditional budgeting.

 Budgeting in agile wasn't something I had given a huge amount of thought to but after hearing Ken explain the benefits, it makes complete sense, here's why... When you budget in an agile way, you budget in sprints, either monthly or quarterly, you can easily calculate exactly how much each sprint is going to cost. 

 On agile projects, cost is usually in direct correlation with project time, because scrum teams consist of dedicated team members, they have a set team cost — generally expressed as an hourly or fixed rate per person — that should be the same for each sprint. Consistent sprint lengths, work hours, and team members enable you to accurately predict development speed. After you determine how many sprints your project will take — that is, how long your project will last — you can know how much your scrum team will cost for the whole project.

Plus you'll also take into account other project costs such as hardware, software, licenses, and any other supplies you might need to complete your project.

 As with any good sprint when you hold the retrospective at the end, you assess whether the budgeting for the previous sprint was effective and whether you need to allocate more money to any particular area, this can help to plan to next sprint.

 With this way of budgeting you can plan accurately for at least a few weeks in advance and if something goes wrong, at least you can put it right with the next sprint of budgeting rather than panicking about how it's going to affect to rest of your year.

 Ken also stressed that it's really important to ensure that everyone is on-board with agile budgeting from the top down, this method of budgeting needs to be embraced by Directors and cascaded down throughout the business ensuring everyone from accounting teams to developers are engaged or it won't be as effective.

 Planning roughly for the long-term or accurately for the short-term? What sounds better to you?

 Please let me know your thoughts either by emailing me at 

You can also find the link to Ken's presentation here: