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 and/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 than estimating? Read on.
Here’s the problem: Up until now, there are two common answers to the question “How much is this going to cost?”:
Stakeholders and decision-makers don’t like answer #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 first hand 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 dollars 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 if it’s worth pursing.
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 4 step, tactical approach to budgeting that takes a fraction of the time than estimating.
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 -
Should we...
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.
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 (i.e. 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 are 1-3 days big. 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 1-3 day 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.
Assuming the decision you are making is at the 1,000 foot level or above. Say it’s strategic like “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 5 high level topics:
Do we have enough info to answer “How Much Is this Going to Cost?” Probably not.
Let’s decompose and 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 week, by Author 1-2 weeks, and Within the Book 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 as to the range of time each of the 5 topics will take, and associate that with a cost, we might wind up with:
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 -
At this point, we’ve spent maybe 2-4 hours. If we would have attempted to estimate this accurately, it would have taken 2-3 days.
The final piece is calculating Confidence levels. We now have enough information to plug the data into Ballpark, a budgeting tool Stride 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 re-calculates 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, 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.
127 West 26th Street
New York, NY 10001
Call us: (212) 634-7240
No Comments Yet
Let us know what you think