Get certified - Transform your world of work today


Why Estimate?

Why we need to estimate stories

19 April 2016

Saumya Nigam
Societe Generale

In my coaching experience, I usually find teams struggling to truly understand the purpose of estimation. It is important to get the basics correct before chasing after other concepts, such as "relative" or "story point" estimates. So let's begin with the basics. All of your thoughts and suggestions in response to these thoughts will be welcome.

Here's an example: If a user story team is able to complete their work in 10 man-days (as per the DOD), it doesn't matter whether we estimate 6, 8, 10, 12, or 14 days. It will likely take 12 man-days, won't it?

Then why are we estimating? Let's try to get an understanding why we need to estimate, and for whom we are estimating.

An estimate will help the PO to:
  1. Prioritize user stories. For example, user stories "A" and "B" will save 50K and 40K euros, respectively, for the end user. Obviously A is a higher priority compared to B. Our estimate is that A and B will take 50 and 10 man-days respectively to accomplish. This is a trigger for the PO to recheck the priority and set the stories in the product backlog accordingly. Here is an illustration:
User story Save Initial priority Team estimated Priority after estimates
A 50K euros 2 30 man-days 1
B 20K euros 3 10 man-days 3
C 70K euros 1 150 man-days 4
D 1K euros 4 2 man-days 2
  1. Communicate “tentative” delivery time to the end user, which helps market the product.
An estimate will help the team to:
  1. Plan/commit what they are able to deliver in the sprint, release, and year (with some variation, say ~20%, depending on the team).
Estimates are not for:
  1. Questioning the dev team in case of delay or a difference between the estimate and reality.
  2. Micromanagement.
Estimates are estimates, not actual effort.

So, estimates have an important purpose.

Now, if we are clear why we are estimating, let's think further about our purposes.
  1. How much time is really useful for estimating any story?
  2. How much accuracy do we want in our estimates?
It is obvious that the more time we spend on analysis and prototyping, the more accurate estimates we will get. But is it really worth spending more time on user stories that are of low priority, or that aren't planned for next 2 to 3 months, or that may even be dropped eventually, due to reasons of scope?

It is always wise to have a balance between accuracy and time spent, instead of striving for ever-more "accurate estimates. Fortunately, Scrum/Agile has came up with a better approach. I will further discuss this, in the form of "relative estimates," in an upcoming article.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (4 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up