Estimates Should be The Start of a Conversation

In the world of product management, the topic of estimates is one that seems a given — we need some idea of how long a given effort is going to take, so that others in the organization can plan around that timeline.  However, it’s become a surprisingly contentious topic in the world of product development.  Particularly in recent years, perhaps exemplified by the #noestimates crowd, comprised primarily of developers and engineers who have had enough of providing estimates that are altered, padded, accelerated, or just completely ignored.  To them, I say, “I get it.” Nobody wants to provide information that’s altered at best, ignored often, or discarded at worst — and often replaced by opinions of non-engineering staff who have no business committing teams to arbitrary deadlines.

The extreme polar position of the #noestimates crowd is certainly attractive in its simplicity. But its allure fades rapidly when the business context of the work that product teams perform within comes to light.  And when we add in all the dependencies that exist on the work that a development or engineering team is doing — the market readiness, the internal and external training, the sales collateral, the reports to the Board or shareholders — we realize that there is just no possible way to live within the business without delivering some form of estimate on work that is in progress.

On one end of the spectrum is the #noestimates philosophy, unworkable because it ignores the context of the business in which product development operates. On the other we have the delivery of uninformed, ad hoc, even non-engineering based estimates, which fail before they are even documented because they cannot possible take into account the complexities and unknowns involved in the product development process.  What lies in the middle?  The answer is that estimates need to be treated with respect, understanding, and as part of the process — estimate should be the start of a conversation, one that continues throughout the product development process.

It’s ironic to me that as Agile took hold throughout the world, we quickly and effectively embraced the idea that a “user story” was not intended to capture the full picture of all possible requirements.  And we as product managers supported the use of user stories (or other alternate methods of capturing Agile “requirements”) as the “start of a conversation”. But we never once stopped to think whether estimates suffered from the same problems that our “requirements” did — when in fact they’re nearly identical.

• Requirements change over time — so do estimates, as work becomes easier or harder as we learn more.
• Requirements need refinement as we learn more information — so do estimates, as the effort to solve a given problem ebbs and flows as we proceed through the process.
• Stakeholders should review requirements and give feedback on what’s needed or not — which changes estimates, given that sometimes taking items away can have the inverse effect on effort.

We’ve continued to practice in a way that embraces change, uncertainty, and new information in one aspect of our work, while utterly denying the existence of such things in another — and one equally important.

Product managers need to start treating estimates from their development teams as the living, breathing things that they are — and engage with stakeholder with such estimates delivered as the start of a conversation.  The initial estimates that we get need to be positioned as just that — strong guesses as to how long a given effort might take. And as we get further and further into the process, we can tighten those guesses into more educated, better informed positions on when a given effort will be concluded.  And with that additional information, product managers can facilitate more directive discussions with stakeholders about the interaction between timing, scope, and quality.

The process by which many companies approach estimation by their engineering teams is as broken as the process that product managers used to use to communicate “requirements” to development teams.  We need to accept this fact and do our best to make estimation a useful tool for guiding difficult conversations, not as an implicit stamp of approval and acceptance before work has even begun.