A section of people doesn’t believe in estimation. The reason they site is that creative process can’t be estimated and it’s supposed to go wrong mostly. If it’s supposed to go wrong anyways, why conduct this futile exercise in the first place.

Having said that, what are the reasons to estimate in Agile methods?

Before we move further, let’s get the following points straight.

It’s important to move towards the outcome (the intent behind a piece of work), work towards the breadth of a feature first and negotiate on the depth (functional richness) of it based on available time and resources.

For instance, it may be possible to create an ecommerce website to ship one phone of a predefined brand in a week or two before working towards shipping phones of multiple brands and taking more time to do that.

This first quick iteration is important to taste the waters, validate/invalidate the assumptions around the product or market, and mitigate associated risks quickly while the team iteratively adds meat to the features.

The problem happens when instead of working towards the intent (outcome), the team just focuses on implementing the static requirements and spend time in estimating them. That is comparatively easier compared to continuously inspecting and adapting the work (similar to Google Map rerouting option) but that doesn’t help in achieving the intended business outcome.

When the intent is to work towards outcomes by becoming agile, big upfront estimations don’t help anyone and instead become waste.

Instead of constraining on scope, time allocation and associated team capacity (translating to budget) can be capped which then can be considered as one of the constraints to build agile solutions.

On a finer grain level though, it still helps to have conversations around estimations because of following reasons:

• The idea is not about the correctness of the estimates. Instead a collaborative guess as a team helps to see if a story is x-small, small, medium, large or extra-large. If the story is big, it needs to be sliced further, or needs to be explored further in case enough information is not available.
• When stories move to a team board without estimates, some go there without proper deliberation and stay “In Progress” for months, some big ones are not sliced further and again take forever to complete. Anything which stays there “under process” or “In progress” for a long time either becomes stale or becomes mere inventory. Any lying inventory in Lean terms is considered as waste.
• The conversations with Planning Poker help to have a shared understanding among team members around the intent, associated ask, and design considerations.
• The team looks at the readiness of the story and takes the story away if enough information is not available instead of struggling to complete it on a road of full of blockers.

More on Story Points and Agile Estimation

This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.