Budget your software initiatives, don’t estimate them
For more than a decade, I stopped using estimations for features and projects. I *budget* them. The more I do it this way, the more I realize this is the right way to build agile software.
When Estimating Software projects are great
If you are replacing an outdated mainframe application or creating the software that controls a nuclear powerplant, estimation-driven planning is a great approach. Two factors make estimation the correct approach: 1) The requirements and the path to the destination have a deep level of detail, or 2) You can’t compromise on the scope.
If you know everything you have to build, if you have all the models and behaviors of the software pre-determined, documented, and have all the acceptance criteria under the sun for that project, yes, you can estimate it. Mostly, what you are estimating is how to translate an English document into code. There is no engineering risk; there is no science (feasibility) risk.
When estimation sucks
Most of us in the tech world are not building the types of the software described above. In our case, estimation sucks nearly all the time.
Writing software is highly unpredictable, and the cost of estimating a feature can be too high to make that activity useful. Let me repeat that to make it clear. If you want to get to a 90% confidence level of how long it will take to build a feature, it’ll take quite a bit of people’s time.
Wouldn’t it be better to use that time in engineering software instead of planning? Most of the time, the answer is yes.
The estimation activity is often not accounted for in planning. And, it causes a catch-22 because you need a cost estimate to do proper planning. Then, after the estimation is done, you are left with fewer people-days to do the work.
What is budget-driven planning?
Every business that’s reasonably run does budgeting. It budgets marketing campaigns, people operations, office costs, software licenses, etc.
Budgeting software engineering is just like that, but you are budgeting days or weeks of a software engineer instead of a financial amount. You already know how many resources you have (the total number of people-weeks for the period). Now you allocate that amount across the initiatives using well-educated guesses and the expectation for the ROI.
Feature X gets three people-weeks. Feature Y gets six people-weeks. Feature Z gets two people-weeks.
There, you budget it.
OK. That’s the oversimplified version of budgeting. You wouldn’t do that for marketing campaigns; you don’t do that for software features.
You must have a sense of what you are trying to accomplish and a reasonable budget to build it. Most importantly, you want to align your budget with the likely effort and value the work should create.
Imagine this: You have two marketing campaigns you plan on running within the quarter, A and B. You expect campaign A to generate somewhere between 800–1,000 new sales leads, while B between 400–500. These are guesses because you’ll only know the results after the fact, but you have an excellent sense based on your experience as a marketer. You still might be completely wrong, but chances are you are within the range. All things being equal, you could spend twice as much on campaign A to get the same value as what you’d spend on campaign B.
Software is like that, to a certain extent. You have a list of many features you wish to build. If you do an excellent job at understanding — even if just at the intuition level — the value that each feature will bring to the customer or the company, you can allocate your budget “chips” accordingly.
Side note: I have used poker chips many times to do quarterly planning by allocating a limited number of chips across all the initiatives we want to do in the quarter. It makes for a fun process.
All right, you get what the idea of budgeting is. Why should you do it?
It’s an investment!
If you work at a tech company, startup or not, the largest cost line item in your P&L statement is people: Their salaries, employment taxes, benefits, the hardware and software they need to do their job, etc. You are converting dollars into people-power. People-power is a limited resource, and allocating it properly is the most critical task to ensure resources are used the best way possible.
Let me list a few of the benefits of using a budget-driven approach instead of an estimation-driven approach.
Benefit 1: Build vs. Buy
One easy way to see the benefit of budgeting is for the “build vs. buy” decision. Do you want to build feature X or use a SaaS product that provides X-as-a-Service? If you know how much it cost X-as-a-Service, you can set the maximum budget to build and maintain X.
Careful here! First, I’m not considering the value of building & maintaining non-strategic software (topic for another post). Second, the fully loaded cost of building and maintaining a feature over its expected lifetime is 2–10X more than the cost of writing the first version. There is maintenance, documentation, testing, CI/CD, DevOps, new features, re-architecture, etc.
Let me give an easy example: Eons ago, Bitly was free, and my startup was using it heavily to generate short URLs for Twitter posts. They came to us one day and told us we’d have to pay $1,500/month for the service, $12,000 per year. Although they had many features, like analytics, custom short-codes, a neat UI to create manual codes, we only used their API to generate a short URL. The fully-loaded cost of an engineer, at that time, was about $800/day. That means the breakeven point was 15 people-days for a year of the service ($12,000/$800 = 15). After a brief discussion with two other engineers on the team, we felt that we could build what we needed in a few days. I gave it a two person-day budget, and we got it done with time to spare. In this case, the maintenance and operations of this feature were trivial, so build “won.”
I also have stories to the opposite of that. Monitoring and alerting is one example. A few great engineers can build a pretty decent monitoring and alerting system to address the product’s needs. However, the budget to build and maintain it far exceeds the cost of services like Datadog, Grafana, or NewRelic. Not only that, these services will evolve and improve over time at a faster pace than my team could do it.
Benefit 2: Known when to pull the plug
How do you know a feature is off the rails? Or, the ROI is not worth it anymore despite the sunk cost? In most cases, teams only realize that a feature has gone way over the original estimation at the end of the Sprint (for teams that are rigorous about their Sprint process) or when it starts to “feel” like it’s taking too long. We all expect software to take a little longer, so when someone says a feature that should take about eight days to build is taking ten days, no one finds it odd. In some cases, people might raise a flag because of cascading effects on other dependencies or a launch date, but not because it was over the original estimation.
However, with a set budget, you tell an engineer that this feature makes sense to build if it cost X but not necessarily worth building if it costs 2X.
Two beautiful mindset shifts happen when you speak like that. Engineers start to get worried when they sense the feature will go over budget. They will themselves raise a yellow flag. Not only that, it happens earlier in the feature work. Going back to the 8-day feature example above, an engineer may raise the yellow flag on day 2 (not on day 10) that this is not what we initially expected. Instead of just plowing through it to get it done, we have a chance to reevaluate the ROI. Should we pull the plug completely? Should we change the scope or the use cases? Should we re-prioritize the work?
Benefit 3: Richer problem-solving with engineers
Here are two messages that a product manager might send to an engineer:
Message 1: “We want to build feature X that does Y and Z. Here’s a draft of the spec. Can you give me a cost estimation of engineering effort?”
Message 2: “We want to build feature X that does Y and Z. Here’s a draft of the spec. We can only allocate 8-days for this work. Can it be done?”
Message #1 will put the engineer in a fixed-scope mindset. They will be excited about the work. They will spend some time digging into the options of how to build it, and they will come back to you with a number.
Message #2, on the other hand, will make the engineer laugh nervously at first. When you hold your ground and say you are not kidding, they will then go into denial: “I don’t even need to think about it. No, it cannot be done!” Then, magic happens. The creative juices start flowing. They will ask you if you can compromise in a corner-case. They will start to think about similar off-the-shelf solutions and bring those to you. They might even tell you that it cannot be done in 8-days, but they can cover nearly all the spec, except for two small things that don’t matter much, in 10-days.
Bingo. That’s what you want. If you believe it’s worth using 10 “chips” instead of 8 “chips” for this feature, go for it.
Another side-effect of this approach is that engineers will be more committed to the budget and the solution. They will work faster and feel more proud of what they achieve. That’s the autonomy they want!
Benefit 4: Build better products
Most products suffer from feature gluttony, not feature starvation. There are many reasons for this. The one relevant to this article is that scope-driven development leads to more features indiscriminately added to the product. PM writes spec, engineer estimates, the feature gets added to the backlog, an engineer builds and delivers it. Lather, rinse, repeat.
Budget-driven is naturally more focused on the outcome than output because it puts everyone in an ROI mindset. Just like the marketing campaign example, you have an outcome that you are trying to drive. The marketer’s goal is not to spend the marketing dollars; their goal is to bring new sales leads.
I believe that budget-driven planning aligns better with the OKR framework, outcome-driven innovation (ODI), and Agile Software Development principles. It puts the benefits for the customer (or the company) front-and-center, not the work.
Also, budget-driven planning leads to a better product because it forces you to think about incremental value creation. Once you set an initial budget because that’s all you can “afford” given the outcomes’ uncertainty, you can work with an engineer to define what can be done with that budget. Do we have enough to build the whole new feature and all its use cases? No? Do we have enough to build most of the features? No? Do we have enough to build an MVP? No? Do we have enough to build a proof-of-concept to prove customer interest?
Even if the cost to build it all is identical in an estimation-driven or budget-driven planning process, the latter lends itself better to build software in phases, which leads to a more natural build-measure-learn approach (see Lean Startup).
Final thoughts/tips
If you adopt a budget-driven mentality for your planning, you have to block a percentage of time for the work that can’t be budget ahead of time. These can be production incidents, mid-quarter customer requests, an urgent/unexpected need from another team, etc. My rule of thumb is 30% is “reserved” for the unknown.
It’s not a buffer — a common practice in estimation. You use buffer to account for the margin of error in estimation, which doesn’t exist in budget-driven planning. The budget is the budget. If you need to go above the budget, you need to increase the initial allocation, but only if it’s justified.
Finally, calculate the actual availability of the team. You don’t want a hypothetical 52-weeks of the year times the number of engineers in the team. You have to account for vacation and sick days, holidays, training and offsites, and even account for new engineers at half-availability.
Conclusion
This post ended up being a longer article than I expected because there isn’t a lot out there that I could reference. I think this is an area there hasn’t been a lot of exploring in the intersection of product management and engineering. I hope to set out a conversation that leads to better software (that serves the customer’s needs) being built faster.
Follow me on Twitter: @calbucci
You might also like:
