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.
Here’s the problem: up until now, there have been two common answers to the question “How much is this going to cost?”
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.
Use the links below to jump to specific sections of the post.
Step 2: Match the precision to the decision you are making
Step 4: Ranges and confidence Levels
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…
Do not proceed to steps 2, 3, and 4 without truly knowing what decision you are trying to make.
Once you identify the decision you are trying to make, your next task is to match the tool to the job. For example:
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.
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.
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:
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
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:
| Topic | Time (weeks) | Money |
|---|---|---|
| Shopping cart | 4–8 | $100K–$200K |
| Browse books | 1–2 | $25K–$50K |
| Search books | 6–26 | $150K–$450K |
| Manage inventory | 12–96 | $300K–$2.4M |
| Preview inside of book | 8–48 | $200K–$1.2M |
| Total: | 31–180 | $775K–$4.3M |
To sum up, our data so far is:
Do we have enough info to answer “How much is this going to cost?” Maybe.
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:
In our online bookstore example, we come up with—
| Topic | Time (weeks) | Money | Priority | Required? |
|---|---|---|---|---|
| Shopping cart | 4–8 | $100K–$100K | 1 | Y |
| Browse books | 1–2 | $25K–$50K | 2 | Y |
| Search books | 6–26 | $150K–$450K | 4 | |
| Author | Y | |||
| Title | Y | |||
| Within book | N | |||
| Manage inventory | 12–96 | $300K–$2.4M | 3 | Y |
| Preview inside book | 8–48 | $200K–$1.2M | 5 | Y |
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.
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—
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—
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.
