A Google search for “creating accurate estimates for development work” yields more than 121 million results. A Google search for “why are teams so bad at estimating development work?” yields more than 47 million. If there’s one thing we all know about estimates, it’s that they’re almost always wrong. The reasons for this are well documented:

• No two developers have exactly the same skill set or develop at exactly the same speed
• Code issues are difficult or impossible to predict
• Availability of other project resources (UX, QA, etc.) can be an issue
• And so on (this article does a good job of outlining more)

And yet we continue to estimate, to make promises and commitments, and to convince ourselves that these wildly optimistic guesses (because they’re always wildly optimistic and they’re always guesses) are more than just that. I don’t need to add to the many millions of Google search results on this topic, but I do want to highlight the clear and direct connection between the commitments we make and our ability to give our teams work that’s both achievable and manageable.

Every product leader I know actively tries to avoid setting deadlines and making commitments, partly because we know our estimates are inaccurate, and partly because we know that deadlines don’t help teams create better products. And yet, making commitments is often unavoidable. When we’re in this situation, I like to remind my team of one very important fact: nobody outside of our team actually knows how long it takes to do our work.

There are lots of strategies for padding development estimates (a Google search for “how much should we pad our development estimates?” yields 35 million results), but this isn’t my point. My point is that, in an effort to force our estimates into pre-determined timelines, we sometimes leave out things that are critically important, like QA and UX. Instead of estimating what it would take to deliver a quality project, we jump right to how we’ll hit a deadline. When we do this, we miss all sorts of great opportunities to negotiate – we give up before we even get started. We also make it impossible for our teams to deliver a quality product on time.

Nobody outside of our team actually knows how long it takes to do our work. This gives us the power to estimate our work as it should be, and to include all the critical pieces that are sometimes thought of as nice-to-haves. It also gives us the chance to bring our business partners along, to help them understand what it takes to build great software, to enlist their help when making trade-offs, and to get their buy-in and support for the recommended approach.

Let’s not forget to take advantage of it.