Nowadays everybody working “agile” knows about estimation, knows, that we estimate complexity, not time, that we estimate in story points, not in hours, that the development team estimates, the people actually doing the work, and not the product manager / team lead / line manager / product owner…
And some also know about the various advantages of agile estimations.
And many people also know, why they can’t do it in their environment. Just the same as many people know, why Scrum “out of the box” is not working for them, their company, their teams, their product (or projects), their environment. Well, well.
But actually, I don’t want to dwell on this aspect here. I want to focus on the outcome of an estimation session.
And yes, I know: it’s not called estimation session, nowadays we call it “product backlog refinement”. And that’s for a reason: it’s not about estimation, it’s not about the one number, that we can tag to the backlog item. It’s about refining the items in the product backlog. And with refining comes exchanging and gaining knowledge, generating a shared understanding, there are shared insights, learning, clarification, identification of open questions, risks, dependencies, meaning, and more… and also a number about the complexity, as a side effect.
How to facilitate this?
Use the different estimations (the numbers!) in the team as hints, that they have different knowledge about a product backlog item or their product and start and foster communication. Ask for insights and opinions. They have reasons. And there will be learning, either on one side, or the other, or on both. And that’s what estimation is about: communication and learning!