Estimation. A hotly debated subject. Virtually everyone and their grandmother has written an article on estimates and why we need to stop doing them. It's even come up in our blog comments. Searching for "#noestimates" on Twitter results in a highly confusing thread of proponents and detractors, vehemently defending their positions. Where do we land here at Devbridge?
Why do estimates matter?
Uber-branded cars have recently been spotted driving around various cities with cameras on top of them, but why? According to Uber (via Techcrunch), they are looking to "improve mapping features that are integral to the Uber experience - such as routing and estimated time of arrivals". Imagine Uber without ride time estimates or estimated fares - not nearly as successful, right? Estimates are useful because they set baselines upon which we can make decisions. Knowing that a car is two minutes away versus 10 matters. Knowing that the ride is probably going to cost you around eight bucks versus $40 allows you to make informed decisions about how you spend your money.
It's the same thing in software development. Estimates are important because they help us make cost-benefit decisions. For most features, ideas, or even projects, you need to understand both how much something is roughly going to cost, and what you think you're going to get out of that investment to properly prioritize. Estimates carry value. We need to do them, despite how much we dislike them.
Why do we hate estimation?
People generally hate estimates for two reasons: how long estimates take to put together, and that estimates are often treated as commitments.
Ask Uber for a fare estimate, and Uber gives you a range instead of a single number. Uber's estimates tend to be pretty good. But every once in awhile, the estimate is wrong, and you might end up spending more than that original estimate to get to your location. Maybe there was an accident on your way home, or maybe there was construction. Maybe your driver just got lost. Regardless of the reason why, you're still stuck paying Uber more than you expected. You might complain to Uber a little bit, but you still pay for your ride, despite the fact that Uber's estimate was not accurate.
Cone of uncertainty
Uber gives you a range because it doesn't know before hand exactly how long it's going to take to get you to your destination. It's estimating based upon currently known information. In software development, we're lucky if we have historical information or knowledge. At Devbridge, we almost exclusively do custom software - something new every time. Traditionally, this would mean that we do a bunch of requirements gathering up front, and then ask developers to assign hours to those requirements. Thats how we get to an "estimate". Usually, those requirements take a long time to gather and vet, mostly because we're afraid of what happens if we're wrong. All that time estimating and no working code!
Why is there fear of what happens if the estimates are wrong? Because estimates are held as commitments - an estimate is a guess, but the expectation for estimates is that a single number is provided and then used as a weapon against the team. The estimate was 40 hours. Why isn’t it done yet? By turning a guess into a contract number, estimates become misused by everyone. For the people doing the estimate, they begin significantly padding their estimates to account for inevitable unknowns, resulting in estimates that hold less value because they don’t represent the actual expected effort.
By turning estimates into weapons, the value of those estimates are stripped away. By asking for a commitment to a dollar number before we’ve even started, we are forced to account for all possible unknowns instead of just the reasonable ones. Uber’s estimates don’t account for every scenario - the estimates are a good faith guess at a fare based upon standard conditions. They aren’t an estimate for your specific ride, and your specific driving conditions. As such, Uber doesn’t commit to that estimate. Software Estimation is similar. Our estimates are intended to be good faith estimates, based upon what we do know. They aren’t intended to be committed to, only to provide guidelines.
So, create lean estimates!
What does this all mean? How do we create accurate estimates quickly while also de-weaponizing them? First, we do the same thing that Uber does: don’t commit to a single number. Instead, we provide a range. Second, we provide transparency in spend throughout the life of a project. We have found that clients and stakeholders are less interested in using estimates as a weapon when they understand early and often what they’re spending to get value. Uber does this via updated arrival times throughout the ride. You can do the same using spend burn-up charts. And third, we use lean estimates to get to high-level estimates quickly, getting nearly the same value with a much lower cost.
If we all agree that we want to maximize the value of an estimate, while minimizing the cost, let’s be lean in our estimates. Bill’s lean requirements are a great place to start. Combine that method with some Agile estimates using story points, and you have a rough estimate on the number of points in your backlog. Divide that by an estimated velocity of a known team, and you’ll have a number of sprints. Multiply that by the number of team members and their rate per sprint, and you’ll have a dollar number. Decide how confident you are in your backlog, and create a confidence interval to get a range.
Lean requirements + some pretty straightforward math = lean estimates. The estimates you’ll get from this process won’t be as precise as if you had taken the time to detail and research each aspect of the product, but they’ll be just as accurate (possibly even more accurate), and will have taken far less time to get to. Maximize your value, make your estimates lean, and deliver more working code.