Subscribe

By: Debbie Madden

Print this Page

November 6th, 2014

Budgeting vs Estimating for Agile Projects

Agile/XP

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.

Budgeting vs Estimating for Agile Projects 

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

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

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. 

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 -

Should we...

  • Start this project or kill it?
  • Hire more people or outsource?
  • Start marketing this feature?
  • Build this project next or deprioritize 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 (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.


 

Step 3: Budget

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.

Example: Online Book Store

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:

  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 decompose and 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 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:

estimating-cost

 

To sum up, our data so far is:

  • The decision we aim to make is: Should we build this Online Book Store?
  • 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 -

ranges-and-confidence-levels

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.

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 -

confidence-levels-in-ballpark

  • If we have a $2.5M budget, we have 100% confidence that we’ll finish our top 2 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 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 -

mandatory-confidence-levels

  • 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:

ballpark-budget-percentages

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.

 

To try out Ballpark, click here.

About Debbie Madden

Debbie has over 20 years of experience in NYC tech. She is passionate about helping businesses improve through software. As CEO, Debbie has unparalleled leadership experience in the technology space - she built 4 companies from the ground up prior to co-founding Stride.

With a reputation as a passionate woman executive in technology, Debbie is a sought after writer and speaker. She has appeared in popular media outlets such as Harvard Business Review, Huffington Post, Forbes and The Wall Street Journal.

  • Connect with Debbie Madden

Related Posts