Much of software development planning is done through estimates. You give me a description of the feature, I give you a best guess on how long it’s going to take. This model has been broken since the dawn of computer programming, yet we keep thinking it’s going to work. That’s one definition of insanity.
What I’ve found to be a more useful model is simply to state what something is worth. If a feature is worth 5 weeks of development, for example, that’s the budget. Such a budget might well be informed by an estimate of whether some version of that feature can be possibly built in 5 weeks, but it’s not driven by it.
Because most features have scales of implementation that are world’s apart. One version of the feature might take 2 weeks, another might take 6 months. It’s all in where you draw the line, how comprehensive you want to be, and what you’re going to do about all those inevitable edge cases.
The standard response to the estimation approach is to propose a 100% implementation that’s going to take 100% of the effort to build. Some times that’s what you need. Nothing less than having everything is going to be good enough. I find that’s a rare case.
A more common case is that you can get 80% of the feature for 20% of the effort. Which in turn means that you can get five 80% features, improvements, or fixes for the price of one 100% implementation. When you look at it like that, it’s often clear that you’d rather get more done, even if it isn’t as polished.
This is particularly true if you don’t have all the money and all the people in the world. When you’re trying to make progress on a constrained budget, you have to pinch your development pennies. If you splurge on gold-plating for every feature, there’s not going to be anything left over to actually ship the damn thing.
That’s what proposing a budget based on worth helps you with. It focuses the mind on what assumptions we can challenge or even ignore. If we only have 5 weeks to do something, it’s just not going to work to go through the swamp to get there. We have to find a well-paved road.
In the moment, though, it can be frustrating. If we just had a little more time, we could do so much better! So much better for whom? Your developer pride? Or the customer? Will the latter actually care about all the spit and grit you poured into these particular corners? Don’t be so sure.
In the end, accepting a budget is about accepting constraints. Here are the borders of scope for our wild dreams and crazy colors. Much of invention lies in the fight within those constraints. Embrace that.
Ilham
on 13 May 14Very nice article DHH. I especially like the last sentence: “Much of invention lies in the fight within those constraints. Embrace that.”
I find that by constraining my choices or actions to only a few things actually releases my freedom a lot more. People tend to over justify the importance of certain things or features, at least in the short term. Where as they tend to under-justify or value other things in the long term.
Guillaume Lerouge
on 13 May 14Agreed, this rings 100% true. In addition to this, when working based on a theoretical deadline, it’s way too easy to feel depressed by the fact that the expected results were not achieved in time (“we should already have this working!”) even though the initial estimate was just plain wrong.
Going David’s way also implies that you should be able to stop working at any given point in time, which pretty much forces you to start with a minimum viable feature and improve it bit by bit as long as you have time – another win!
Michael
on 13 May 14By embracing your constraints they point you toward the solution. Business (and life) is about getting the best outcomes within the constraints that define our situations. Ironically, if we have all the time and all the money we feel we need then there is no urgency to do anything. And without a sense of urgency, development projects become leisurely voyages to nowhere.
Zillion dollar development projects fail because of all the complexity that inevitably arises when people have too much time and money. The more people study a situation, the more complexity they perceive, and more and more features are added to respond to the perceived complexity. The best way to be successful with big dev projects is to break them into an on-going series of small projects of a few weeks each. And keep a sense of urgency running through each of the small projects.
Glen B. Alleman
on 13 May 14And what confidence intervals do you place on those “Budgets.” This approach based on budget, has a familiar ring with Earned Value Management, where the Budgeted Cost of Work Scheduled, is the “worth” of the deliverable
Albin
on 13 May 14Totally agree with you. I believe software development should be driven by the “value addition” factor, rather than the “creative self satisfying design” factor. Although that does not mean, providing bad code in too short a time, but it definitely avoids the time lost on the gold plating you were talking about. And of course the “kick” of finding out a solution within the constraints.
drawtheweb
on 13 May 14Right on DHH. We have a similar mentality around here. It took a while to get there though as the typical exchange came across sounding something like:
CEO: “How long will the geolocation cloud graph feature take?”
Product Team: “That depends. How much you got?”
So long as everyone agrees that the estimate based forecasting is broken, (which they will if you review your track record of estimate vs actuals), then this is a more informed way to work and celebrate success.
Deriving the ‘worth’ is a bit of black magic though, but we use an evaluation of:
- % of user base that will use the feature
- will it help us sell more, and if so, how much
- potential risks to product stability or performance (we have a huge product)
- costs to implement, train customers on and document said feature
Peter Nush
on 13 May 14Great article, and I think it’s pretty easy to agree in principle, but there are a couple of assumptions being made about estimates (which I unfortunately see people making all the time), and that’s where things go wrong.
If the estimate is a delivery date, then that’s a mistake right off the bat. That assumes all dependencies have been accounted for, including developer sick days, emergency patches, etc. and is just plain unreasonable. I would hope that’s a pretty well accepted error at this point.
If the estimate is a duration generally, then that is effectively the start of a budget, right? If you estimate 5 weeks, then that’s a “cost” for that feature that can be weighed against everything else you have on the backlog. If that’s higher than you were expecting, that should spark the conversation that asks, “What could I get in 2 weeks?” which leads to the 80/20 outcome. However, this still doesn’t account for the unexpected…
If the estimate is a duration with a range, then you have the option to negotiate scope to get to the core of what’s most important (e.g., the 20% effort to get 80% value) more rapidly, and still be sensitive to the unexpected. The last time I checked, no one was fired for delivering early…
Lastly, if the estimate has no context, for the recipient, then they are not going to make a good decision with it anyway… What do you mean a gallon of gas doesn’t cost $0.75 anymore? That’s my budget! That speaks to who you hire, what roles they play on the team, and so on, but it’s important nonetheless.
Lauree Roberts
on 14 May 14Agreed. The whole software development planning is done only through estimates. The client explains what all features he needs in the software to be developed and the Business Analyst just assumes the time, budget and effort needed for the whole process of Software Development. Here, the skills of the Business Analyst as well as Developers and the co-ordination between them matters a lot.
Tim Bailen
on 14 May 14Well said. It fleshes out a quip I heard from a director at Transit Now Milwaukee: “a budget is a vision and planning document.”
Your post also reminds me of some good thinking that agilist J. B. Rainsberger shared recently:
“I recommend treating estimates as budgets, so instead of saying, ‘This task will take 2–3 days’, try saying, “We can afford/justify spending 2–3 days on this task.’”
It’s a helpful language hack, he says.
“If we express our situation as a budget, then we can feel a subtle compulsion not to go over budget. When I interpret ‘3 days’ as a budget, then later realize that I can’t finish the task in 3 days, I feel more open to considering what I can finish in 3 days.”
His third point is that estimates make us think about cost, but budgets make us think about value, which is… more valuable.
(His full article is at http://www.jbrains.ca/permalink/a-critical-step-towards-noestimates)
Gstaov Martins
on 16 May 14Although this idea is very appealing for a software developer like myself, I’m not convinced it would work.
Imagine the marketing people at your company do a study and come to the conclusion that moving the buy button to a different place and changing its color will increase sales in 25%. The decision maker would think: “this change will increase my sales in 1M, I’m willing to spend 200k to make it happen!”. Budgeting based on value can produce results completely dis-adjusted from reality.
Wouldn’t it work better if the business people estimate the value of a change/feature and ask the dev team for a high level estimate (between 50k and 100k) and, with those two in hand, make a decision and allocate a budget? This budget can then be used in an agile project that can still deliver 80% of the value in 20% of the time, if the team creates shippable software per sprint.
I’m not sold on the No Estimates thing. At least not yet :)
James Conway
on 16 May 14I think this comes down to people focusing in the wrong areas to try and be productive. Scrum is dead. Take a look at my lates post Go home Scrum, You’re Drunk!
This discussion is closed.