Budgeting vs. Estimating for Agile Projects

Nearly every software development project starts with one question: “How much is this going to cost?”

Perhaps it’s a stakeholder who asks the question: a CEO, board member, VC, or boss. Maybe you’ve asked your team this question. Maybe you’ve asked it another way—“How long will this take?” Or, “How many stories can we get into this next sprint?” Or, “What’s your velocity?” Or, “How many people do we need to hire to get this done?” Or, “How much money do I need to raise to launch an MVP for my startup?”

These are all variations on the same thing—how much effort is this going to cost, in terms of time or money.

How many of you have been asked or asked someone else this question? Want to learn a powerful way to answer it that takes a fraction of the time that estimating does? Read on.

Looking for a Better Way to Estimate?

Budgeting vs. estimating for agile projects

Here’s the problem: up until now, there have been two common answers to the question “How much is this going to cost?”

1. We don’t know.
2. Let us estimate and get back to you.

Stakeholders and decision makers don’t like response #1 because they desperately need an answer to their question, and they don’t have the knowledge to answer it themselves. And technical teams don’t like answer #2, because estimating takes a ton of time, and it’s often abused (stakeholders sometimes turn the estimates into maximums and get upset if the team exceeds them). See my post on A History of Estimating and Why It’s a Waste of Time.

Yet the truth is: It’s the responsibility of the technical team to answer the question “How much is this going to cost?” Why? Because technical teams are the ones that have the most relevant knowledge to answer the question. If I ask you, “How much does it cost to build a ballpark?” only those of you who have firsthand experience building something similar can truly answer. The rest of us are taking a stab in the dark.

Here’s the thing. “How much is this ballpark going to cost?” is a fair question. Do I need to buy a shovel so I can build a sandlot? Or do I need to raise $100 million to build Yankee Stadium? Stakeholders have decisions to make around cost benefit and budgeting. They deserve to have an idea of what their investment is going to be—and whether it’s worth pursuing.

So how can you satisfy the stakeholder’s need to know “How much is this going to cost?”

Answer: Stop estimating; start budgeting.

Here’s a four-step, tactical approach to budgeting that takes a fraction of the time that estimating does.

Four tactical steps to budgeting

Use the links below to jump to specific sections of the post.

Step 1: Identify decisions

Step 2: Match the precision to the decision you are making

Step 3: Budget

Step 4: Ranges and confidence Levels

Step 1: Identify decisions

Before you even begin to think about budgeting—or estimating, for that matter—it is absolutely critical to know what decisions you are trying to make. What will you do once you have the data? What are you trying to learn? Some examples of decisions you might be trying to make are:

Should we…

• Start this project or kill it?
• Hire more people or outsource?
• Start marketing this feature?
• Build this project next or de-prioritize it?
• Launch a startup?
• Allocate budget this quarter?
• Code this set of stories next?

Do not proceed to steps 2, 3, and 4 without truly knowing what decision you are trying to make.

If you can’t identify which decisions you are making,
both estimating and budgeting are a waste of time.

Step 2: Match the precision to the decision you are making

Once you identify the decision you are trying to make, your next task is to match the tool to the job. For example:

• If you are trying to make a decision at the granular, 1,000-foot level or below (e.g., “How much will we get done this iteration?”), estimating is a good tool for the job.
• Otherwise, for more strategic decisions like many of the ones listed above, budgeting is a more appropriate tool.

Estimate only when necessary

For a typical agile team, many stories take 1–3 days. For a $1M project, that’s a lot of stories to estimate. Even for a $100K project, that’s a lot of stories. If you attempt to break the entire thing into user stories at the beginning of the project, you are really just wasting your time and not gaining any info that’s going to truly help with a high-level decision. Why? Because there’s no way that you are going to get estimation at a granular level correct at the beginning of a project.

Step 3: Budget

Let’s assume the decision you are making is at the 1,000-foot level or above. Say it’s about something strategic, such as, “Should we build this product?” “How much money should we raise?” “Which of the Q1 projects should we prioritize?” When the decision you are making is strategic, budget using a top-down approach and decompose only as far as you need to in order to have enough information to make your decision.

Example: Online bookstore

Let’s say we’re building an online book store. What might we need to build it? Maybe we’d want to have these five high-level features:

1. Shopping cart
2. Browse books
3. Search books
4. Manage inventory
5. Preview inside of book

Do we have enough info to answer “How much is this going to cost?” Probably not.

Let’s break down “Search books” into more detail. Maybe we want to search by

• Title
• Author
• Within the book

Because someone on our team has built a search component before, we can say that search by title will take 1–2 weeks, by author will take 1–2 weeks, and within the book will take 4–16 weeks.

Do we have enough info to answer “How much is this going to cost?” Probably not.

If we take a ballpark guess at the range of time each of the five topics will take, and associate that with a cost, we might wind up with:

To sum up, our data so far is:

• The decision we aim to make is: Should we build this online bookstore?
• We expect the project to cost $775K–$4.3M.

Do we have enough info to answer “How much is this going to cost?” Maybe.

• If our budget is $500K, then we do have enough information. The answer is no, we can’t afford it.
• If our budget is $5M, then we do have enough information. The answer is yes, we can afford it.
• If our budget is $2.5M, then we do not have enough information.

Step 4: Ranges and Confidence Levels

If our budget is $2.5M and we need more information, we need to assign confidence levels to each topic. To do this, we need to:

1. Prioritize the topics
2. Identify which topics are “must haves” vs. “nice to haves”

In our online bookstore example, we come up with—

At this point, we’ve spent maybe two to four hours. If we had attempted to estimate this accurately, it would have taken two to three days.

The final piece is calculating confidence levels. We now have enough information to plug the data into Ballpark, a budgeting tool Stride has developed.

Confidence levels in Ballpark

Ballpark is a budgeting tool. It takes the input from a few hours of budgeting, as done above, and simulates thousands of possible outcomes using complex mathematical calculations, and in a matter of seconds spits out confidence levels that you can use to have a powerful conversation with your stakeholder to answer the question once and for all “How much is this going to cost?”

In this case, Ballpark tells us—

• If we have a $2.5M budget, we have 100% confidence that we’ll finish our top two priorities within our budget.
• 86.5% likelihood of finishing “Manage inventory”
• 59% likelihood of finishing “Search books”
• And 23% likelihood of finishing “Preview inside books”

It also recalculates confidence levels once the non-mandatory items are removed. In this case, we state that “Within book” isn’t mandatory. We can then rerun the simulation without “Within book” and learn that if we only look at our mandatory, “must have” topics, we get—

• 81% likelihood of finishing “Search books” within our budget
• 45% likelihood of finishing “Preview inside of book

Ballpark also tell us percentiles of the likelihood of each budget range. In the Online Bookstore example we see there’s a 50% chance we’ll get the entire project done for $2.75M:

At the end of the day, it is the responsibility of tech teams to give the stakeholder the answer to “How much is this going to cost?” Estimating is often a time sink and not worth the effort this early on, and with higher-level decisions. Budgeting is extremely cost effective, and it can be done in about 20% of the time that it would take to estimate. And Ballpark is the missing link, the tool that creates confidence levels using mathematical simulations to give tech teams the tool they need to be able to answer this question quickly and reliably.