The fallacy of Estimating the Product Backlog Items

What we still don’t get about estimates even after decades of executing projects and building products is – estimates are always imprecise by nature.

We human beings are horrible at predicting how long it takes to do something we don’t know. Exploring the future is always filled with uncertainty and hence the challenge we have even with so much of the process built around estimation.

The tension between the ones who ask for a deadline and the ones who provide estimates is going to prevail unless both come to terms with reality.

The reality being – we don’t know everything upfront and estimates are meant for gaining a shared understanding.

Let us take a step back and look at what happens in the absence of this understanding.

We know everything upfront

An illusion of having control over uncertainty in the future creates a mindset to urge immediately to discuss how to implement the Product Backlog Items in estimation discussions.

Most of the Developers (was ‘Development Team’ in Nov 2017 Scrum Guide) deviate and focus on an implementation even before providing estimation. Moving into the solution space upfront is a trap without exploring much on the problem space. This pattern of discussing ‘Technical – How to Implement’ will only end up adding more feature/functionality to the existing product suite and not every time solving the problem in turn with this approach.

Given the assumption of knowing everything upfront changes our focus in estimation conversations.

Estimates are beyond shared understanding

When estimates are not meant to create a shared understanding, the Developers don’t tend to be curious in understanding fellow developers’ views on how to solve the problem. Using estimation conversations to collect an arbitrary number tagged to individual Product Backlog item and taking oath on getting it done, waters down the significance of what the team can achieve together.

As long as the shared view on why we building and for whom we are building are clear to the team, everything else becomes details. Everything which includes the numbers and associated arithmetic the team tends to perform.

No Product Owners talk about this arithmetic with the stakeholders and customers instead it is that shared understanding followed by Sprint Goal arrived as an outcome in the Sprint Planning. Product Owners should encourage the discussion around the estimates than quickly tagging the estimates to the PBIs.

Remember the next time as a team we are not going to discuss the what and how unless the WHY is clear among the team.

“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.” ― Marty Cagan

Wrap up!

Accepting that we don’t know everything upfront is one of the key traits of embracing an Agile mindset. If we continue to perfect the estimates, we are not yet there being Agile.

Start using discussion around estimates as an opportunity to build a shared understanding. The discussion should always revolve around why this problem and why we want to solve the problem so we find better solutions together as a team.