How to budget when planning is so fluid?

The Problem

Budgeting with Agile shouldn’t be a difficult task. You’re running or starting an Agile project. You have to budget for a new project. You have to ask for more funding to move to your existing project. You have to get approval to start a new project. You have to get investment for a new tech startup.

What do you do? 

I’m going to focusing this content on an established business, not a startup. Here’s the natural asks that come out of most people; 

1. How many sprints are you going to need?
2. What is your release plan per sprint? What stories will be completed per sprint?
3. What’s the breakdown of people, time and cost?
4. When will you start your first sprint and when will you end your last sprint?
5. I need to see your work breakdown structure?
6. Where’s your project plan?

Many of those questions don’t have a very Agile mindset to them, do they?

You will spend time doing detailed release plans. You will spend time with large planning sessions to think of everything that needs to be done within a release. Filling in a work breakdown structure, or work breakdown structure’like format. You don’t want to use a Gantt chart, but you create a Gantt chart’like slide. Ultimately you will spend a bunch of time and money, which takes the team away from delivering value, trying to be as accurate as possible. 

The outcome is a false sense of security. 1 of 3 different things will happen:

1. You will focus on running agile. You will continue to operate your team in an Agile manner, and when priorities change, the team adjusts, and your planning will be wrong. I’ve seen this happen as early as the first two sprints. In one case there was a 3 week and $60,000 investment for it to be flipped within the first 4 weeks of execution. You will have to spend time and money either managing micro updates to your plan, or you will have to justify later why the plan was perceived as failed
2. You will focus on the plan. You will not allow your team to adjust priorities, adjust to any changes, or really operate in an Agile way. Following the plan is more important, which breaks the fundamental Agile values. You will ultimately deliver to the plan, but the business won’t be happy as important items that came up were ignored. They may get what they ask for, but they end up with a laundry list of high priority changes right away. 
3. You got it right! You estimated the plan properly and accurately. The team delivered to the plan to a “t” and the business is happy! Before telling yourself, you’ll just do this, ask yourself, “How often has a plan never required a change? How often has this happened?” It’s the exception, not the rule, especially in software. Planning for the exception to be your factor to success is just bad planning. 

Ok… so we can’t estimate the old way… we understand we’re going to waste time and money for a false sense of security… what do we do?

The Value

Before diving into how we can handle this, first let’s ask a different question, why do we need to budget? What’s the purpose, or better yet, what’s the value to budgeting?

I’ve interviewed a number of clients and colleagues of mine and come up with 2 common values to budgeting;

1. We need to understand where we’re investing money, how much, and the ROI. 
2. We need to understand if we invested properly

Ok. So we need some level of confidence on how much something is going to cost and at the end did, we spend properly.

The How

First off, this, which is true of any real progression within Agile, only works when you run proper Agile teams;

1. A team is a dedicated delivery team. 
2. Members are 100% allocated to one team
3. Teams have 1 Product Owner
4. Teams are self organizing

In the context of this article, I’m only going to focus on Value item 1. I’ll follow up with Value 2 in another article. 

A stable, dedicated Scrum team has a burn rate. It’s so many employees, contractors, or any other overhead per Sprint. The burn is steady.

Every two weeks, the team burns ~$30,000 in cost.

A team has a velocity. That is the approximate amount of points a team delivers within a Sprint. 

The teams velocity is 30 points a Sprint

If you’re team’s velocity is not very consistent, then that’s an issue that should be tackled. Outside of budgeting, a steady and even track record is crucial to the Agile Mindset. Is the team going to be perfect every sprint? Of course not, but they should be more consistently hitting their velocity than not. 

With a teams Burn Rate and Velocity, much can be determined. 

So let’s talk about planning. 

There’s a couple ways I’ve seen teams do planning;

1. Stable backlog with a release worth of stories estimated at the top. Typically a backlog has about 1.5-2.5 sprints worth of stories at any point in time, so this can break that rule slightly. Spending time planning out stories that could be de-prioritized later, or does it?If you’re Definition of Ready (DoR) for a story is set within your team, and stories have to, at least, contain a story statement, some sort of description, Acceptance Criteria, and an estimate, then you already have a stable backlog. Does it mean every story has to be detailed? Nope. Just that enough detail is there that a comparable sizing can be done (Story 111 at 8 points is larger than Story 222 at 5 points). If each story follows that format, then you have a backlog of estimated stories. 
2. Epic (or Feature for those using Azure DevOps) based release planning and estimation. Similar to stories, you have a comparable sizing of Epics (Epic 111 at 8 Points is larger than Feature 22 at 5 Points). I’ve seen companies also use a summation of Points as well (Feature 111 took 80 points of effort in Stories and Feature 222 took 95 points, Feature 333 is about middle so we’ll call it 88). 

However you do it, you have a stable and estimated backlog of work. Stable meaning, there’s enough detail to compare sizing and estimate Stories or Epics. 

There’s a couple ways to tackle release planning at this point. The easiest one is to look at the teams velocity. There’s 3 main ways to look at velocity.

• The team has a normal Velocity of 30 points (that is most sprints they plan and complete 30 points worth of work)
• The lowest Velocity of a recent Sprint was 23 points. 
• The maximum Velocity of a recent Sprint done by the team was 34 points.

One aspect to estimating is if you have a fixed timeline (what will you deliver within the next release, quarter, or x number of Sprints?). Using a stable Backlog, a team can better estimate where they might end up:

When it comes to determining the number of Sprints a Release will take based on scope, it’s similar; 

In either case, it’s always good practice to add a contingency. My magic contingency number is 30%. Why 30%? For whatever reason, retrospecting on past clients of all different sizes and industries, this has been a consistent average of what I like to call the Estimation Error Rate. We, instinctively under estimate, especially larger items, by an average of 30%. 

Story time – I was at a large scale Oil and Gas company when someone challenged this number. They were using the Epic based option for estimating releases based on a summation of the Stories Points estimated to complete the Epic. My answer was simple, “let’s do the math”. I had no idea what the specific outcome at this company would be, I hadn’t done the math for myself yet. We went to the board and did the math. We picked two large Epics that were completed the previous release, took the initial estimate of points and compared it to the summation of the actual points of the stories that were completed to realize the Epic. The first Epic was 33% under-estimated, the second one was 29% under-estimated. The magic 30% number was validated! I can’t guarantee it’s accuracy for you, but since I started using it about 8 years ago, my overall degree of accuracy has increased dramatically.  

Incorporating a contingency in the fixed timeline model above, I’d simply take each estimate and reduce it by 30%

• With the worst velocity, we’ll complete 106 points
• With the average velocity, we’ll complete 138 points
• With the best velocity, we’ll complete 157 points

With a fixed scope model, I’d add 30% to the total Points and use that to reflect the number of Sprints

• The scope related to the “Release” is now 292.5
• With the worst velocity, we’ll be complete within 13 Sprints
• With the average velocity, we’ll be complete within 10 Sprints
• With the best velocity, we’ll be complete within 9 Sprints

Ok, that’s a lot of math, but nothing too crazy. Let’s bring it back to budgeting;

With a fixed burn rate of $30,000, the fixed timeline model above is easy to estimate. 6 Sprints at $30k a sprint is a total budget of $180,000. 

With the fixed scope model. You’re looking at between 9-13 Sprints of work. That equates to a budget between $270,000 to $390,000. As I’m confident in the method, I usually stick to the “Average” estimate. With a contingency factor, and understanding some sprints might be under, but some will be over, this is usually quite accurate. With that, the estimated budget for this project is $300,000.

As long as the team continues to take any changes or adjustments to the plan and prioritize those against the existing backlog items, whereas the highest value items will always be worked on first. When it comes to the end of the project/budget/timeline, the only items that may be remaining should be ones that are deemed as lower value. If you ended up with higher value items that you pushed off, then you didn’t properly prioritize the work. 

When we talk ROI. We want to realize the highest value for the lowest investment. That’s the basis for how stories should be prioritized, based on business value. Not that we can’t negotiate based on technical guidance as well, if we do Story 123 first, it still has value and will actually better set us up for the other 3 stories of higher value more efficiently. 

Where some teams go wrong, is they take a stance that some work is really complicated, so they push that out in the timeline to do other, quick win items sooner. But if those quick wins are of lower value, and you’re running in an Agile Mindset, adapting, adjusting, and collaborating, at the end of the project, you’ve delivered a lot of great, potentially low value work while high value work is not complete. 

Conclusion

With a stable, agile team, running with an Agile mindset, planning and estimation becomes part of the process. 

Create a standard for what stories require in order to be in the Product Backlog. That doesn’t mean template the crap out of it… it means set a high level standard for the minimum required for a story to be ready. INVEST is a great framework for this. 

With stable, estimated stories in your backlog, some simple math gives you release planning and budgeting. 

I always look at trying to use what a team is already doing, or should be doing to get extra level of reporting. If you’re creating extra work to get data out of your team, you’re choosing to take money away from delivering value. If ROI is something that’s important to you, then consider this, if you spend, let’s say $30k to get a detailed plan, estimate, work breakdown structure, and those plan can change as early as within the first couple sprints of a project, then what was the ROI on that $30k?

 >> Interested in booking some time with Jamie to talk Agile? Click here and book a quick 30 minutes!<<