In a recent newsletter titled “Roadmaps don’t create a product; Releases do”, Denis mentioned

there are two parts to estimates:

• Forecasting completion of the solution
• Communicating our understanding of the problem

That had me curious, as I’ve experienced both sides of that coin.

From my observations, there’s more of an emphasis on forecasting the completion, and not enough attention is paid to communicating our understanding of the problem.

I asked him

In an ideal world, how would it look to separate communicating understanding of the problem, and forecasting completion?

and he shared a few tactics in each category.

For understanding:

• repeat back to your experts what it is they want until they agree
• acceptance criteria: “How will we know it’s valuable?” / “How will the user benefit from this?” / “How will we know the is being used as planned?”
• building something to create knowledge, ie. a prototype or an integration POC

For forecasting completion:

• separating waste from the core functionality
• releasing incrementally polished iterations, where each increment is done (rather than 7 different parts and only number 8 is the first version of “done”)
• setting strict deadlines for launching a severily under-polished MVP (static pages, limited functionality, manual data manipulation)

Related reading

I can’t help but think being a more product minded engineer will help one to provide higher quality estimates. I round up a few articles here.