The Truth behind Software Development Estimates
The larger the effort, the more we need to estimate—and the more the estimate will be wrong. (Just look at the HealthCare.gov site fiasco.)
The problem with estimation is that software is not construction. We can’t create software the same way we build a house or manufacture anything else. We can't say, “We can build this software for x dollars per square foot” because we have not built this exact software before. If we've built software like this, we can estimate pretty close because we either have historical data with good estimation quality or we have small chunks of work we know about.
But other people often think of our estimates the way they think of estimates in other fields such as construction, especially if you provide a single-point estimate. What can you do to set the record straight?
One method that helps is to make your features really small. Swarm (or, as Woody Zuill says, mob) over every story every day. Finish at least one story each day. If you always have deliverable software—this includes all tests, documentation, everything you need—you don’t need to estimate anything. You also gain the benefit of learning. So if someone asks “How hard is this to do?” the entire team can say, “It’s this story and that story and this story, too.”
It's worth asking yourself, your team, and your management why you estimate at all. If it's only because that's what you've always done, maybe it's time to reconsider. Generally, it's for these reasons:
- We need to provide an order-of-magnitude size, cost, or date for the project so we have a rough idea for planning purposes. An order-of-magnitude size means we want to invest just enough time in the estimate that we believe in the accuracy of it for planning purposes.
- We want to know when we will be done because we are close.
- We need to allocate money, teams, or people for some amount of time.
- Someone wants to know whom to blame.
If you need an order-of-magnitude estimation, that doesn’t take days to determine—it takes hours. It will be precise-wrong and order-of-magnitude-right. Timebox it, but don’t hold anyone to that estimate. (After all, the definition of estimate is "guess.”)
If you want to know when you’ll be done because you think you’re close to the end of the project, ask yourself: Is it worth the time to estimate versus the time to finish? It might be. But know you are taking time away from finishing.
If you estimate because accounting wants to do once-a-year money allocations, well, you know that’s fiction. You can do that without detailed project estimation. For money allocation, decide how valuable the project is to you. Now, tell the project team when the value has to be delivered. That’s all.
And if you just want to play the blame game, remember that management is the one who needs to shoulder the most blame. Why? Because management set the constraints.
When creating software, you should want to see working software as you create it, because with software, we learn. The learning is what’s most valuable—not the estimate.
