Scrum annual budgeting

One of the repetitive questions which people asked me is, how do we do annual budgeting? Now when this question normally comes up, what the person asks is that they try to find out how much it costs to deliver a whole piece of features requested. I usually turn this question around on the questioner and ask her/him how do you do it without Scrum? and how accurate are you? Typically the answer is, they just guess and the accuracy is pretty poor.

To me, when someone asks me this question, means that the questioner has this presupposition that Scrum should be able to do this with 100% accuracy. In other words, the questioner is just asking for magic.  The truth is Scrum doesn’t do magic.

The importance of project budgeting lies in the ability to eliminate excessive expenses and assign the correct amount of the budget to each need. Now for answers to the question, we need to answer the following questions:

1. How much time do we need to internally buy on the team(s) that work for a company to get that work done?
2. Do I have enough people to do that work?

The answers to the above questions are not easy to find out before you dive in. Also, I would suggest, Instead of sticking to providing a bunch of features and getting constant deadlines, try to vary the list of features. You’re can have increment on a certain date, but not know what the features are or you can have all the features and not know what the date is. You can’t have all the features and the dates at the same time. Besides, if you follow Scrum then:

• Feature list becomes variable and it’s going to be the Product Backlog.
• You’re going to work in a series of Sprints and you’re going to do the top priority items on the Product Backlog first.
• You’re going to deliver done, working increment each Sprint and you’re going to provide an option to your company to cancel the project at the end of every Sprint or some number of Sprints.

The idea here is that if you’re not delivering done, working increment or the company has enough or the company has decided they don’t need it anymore, then don’t spend any more money on the project. Also, If you deliver done, working increment every sprint, so theoretically, you can just kill the project at any time and just live with what you’ve already built.

Companies that follow Scrum think about budgeting as follows :

• They think about funding a Product Backlog.
• They think about funding teams for certain numbers of Sprints. Teams are going to work to Definition of Done.
• They’re going to cancel the project if it’s not working. The focus is going to be on the cost of the team per Sprint rather than the cost of the piece of features that they dreamed up.
• It’s going to tend to be cheaper because they’re not going to build what they don’t need. They’re always building the high priority stuff. When they get done they’re not going to do that whole Product Backlog. That Product Backlog is going to be the list of dreamed features and there’s going to be a lot of stuff that’s leftover.

In short, you just need to think differently about how you do your budgeting. Cost of the team per Sprint, that’s the number, and there you have it, Scrum annual budgeting.

Thanks for reading the Scrumsaturday.com! Take a minute to follow me on Twitter if you enjoyed this post and want to see more.