Agile Estimation:8 Steps to Successful Story Point Estimation

by Avienaash Shiralige

In Story sizing, team does a comparative analysis between all of the stories for the project. Let’s look at the typical story sizing steps.

For each story to be sized, do the following as a team(Product Owner, Core Scrum team including developers, testers & scrum master).

Agile Estimation

1. Identify base stories.

It is very important to identify one or multiple base or reference story against which you would do relative sizing of the backlog. This story is picked from current product backlog or a different story which we have done earlier. But what is important is the understanding of this sory is same among everyone on the team. Team should be confident of this base story.

2. Talk through the requirements of the story.

Product Owner or Proxy PO, will answer questions and provide explanation about what exactly this story entails.

3. Discuss and jot down things you want to remember when implementing this story.

These can be bullet points on the story card or text in the “notes” section of a tool. This is best done by Scrum Master who can add these details as and when discussions are on.

4. Some of these questions team ask themselves when they start sizing.

1. Design: What will we have to learn before we can start work on this story?

2. Coding: How much code will need to be written for this story? Have we written similar code before?

3. Unit Testing: Will any special setup (e.g., mock objects) be required to unit test this story?

4. Acceptance Testing: How much work is involved in helping the customer to automate the acceptance tests for this story?

5. Integration Points: Does this story have external dependencies?

6. Expertise: Does anyone of us have done similar story before?

5. Find some point of relative comparison.

If this story is about the same amount of work as one you have already sized, give it the same number of points. If it is more difficult, give it a proportionally higher value. If this story is similar to another but less work in some way, give it a lower value.

6. Reach a consensus among entire team present as to the size of the story as per definition of done.

7. Validate that your estimates are internally consistent among stories as you go along.

8. Periodically ensure that all of the 1’s are about the same, all of the 2’s match, etc.

Likewise, the team should agree that a four-point story is roughly twice as much work as a two-point story.

In story point estimates, it does not matter if your estimates are correct or incorrect as long as you are consistent. We will talk about this and many other aspects of estimation in coming posts.

So what is your experience in using this technique till now? Please share.

Spread the love
Gurdarshan Singh Matharu June 19, 2012 at 6:44 pm

Dear Avienaash,

I have used two different estimation technique i.e. Poker card and SWAG, in both the cases we in the first two sprint follow what you said that take some base story and first estimate that base story and then estimate rest of stories around that base story estimate.

But as per my view, after some sprints, we normally stopping following this process i.e. take a base story and estimate rest story around this story estimate, because after some sprints lapsed we able to get hold of the requirement and know how much effort is there in each task and where we need to do.

But yes initially this practice hold goods and set a base for future sprint planning and also hold goods for estimating the task of each story.


Avienaash Shiralige June 20, 2012 at 7:06 am

Yeah After few sprints team gets used to base story and they get comfortable in estimations. But still there is a need to poke the team after every few sprints just to make sure they are churning good numbers. Scrum Master or an Agile Coach can smell the need for regrouping and they would remind the team about basics. Even you pick any seasoned scrum team, you see a need to talk about basics multiple times in the life-cycle of the product or project. Also I would suggest apply story point estimates at user story level.

Antony June 20, 2012 at 8:10 pm

We’ve built a whole set of base user stories with their story point estimates over multiple releases. This enables us to quickly see similar stories we’ve estimated in the past, and give similar size.
Also I’ve found that the scrum master needs to consistently remind the team to do triangulation (comparing current story with at least 2 other stories) before selecting their estimates.


Avienaash Shiralige June 22, 2012 at 10:35 am

I agree with you. Triangulation is very helpful.

Andre August 8, 2012 at 12:58 pm

Thank you for an good article

I feel that we follow these 8 steps, however I have a question (bare in mind I’m not an expert):
We estimate storys with story points in the backlog, and in the sprint planning meeting we take this storys and break them down in to tasks to fulfill the story. We then estimate in hours. But in this process we find that we some times see “new sides” (read: extra work) to the story leading the original stroy point estimate to be wrong. Is this OK, and just update the story point estimate? Comments…

We use planning poker for both excercises.


Avienaash Shiralige August 20, 2012 at 11:41 am

It is completely fine to see some extra work after you breakdown. But I follow a practice of not updating point estimates unless it is vastly different. Because point estimate is coarse grained estimates and let it remain that way. Positive and negative variance gets cancelled over 30-40 stories which you will find only in a release. Because each iteration maximum you may take 5-10 stories and this sample is very small to cancel point estimation variance.

Hope I am able to explain it well.

Mayuresh November 20, 2013 at 2:43 pm

Why in agile estimate are in story points and not hours?

Shrikant Vashishtha November 22, 2013 at 1:19 pm
Avienaash Shiralige January 17, 2014 at 2:17 pm


Just by reading posts you may not find it easy to get power of story point estimation. I would suggest you work with such teams which uses it extensibly or with a coach or attend a training who believes strongly in it.


Priya Vikas May 1, 2014 at 10:03 pm

Hi Avienaash,

My team tends to include any demos that need to happen around a user story in their estimation process. In my mind any sprint activities should be excluded from the estimation and capacity calculations. What are your thoughts on this?

Avienaash Shiralige May 31, 2014 at 9:15 pm

You can use focus factor to address this. I have blogged about this earlier. Check it out here.

Cynthia February 8, 2015 at 12:41 am

Hi Avienaash,

At times there are disagreements within the team in the estimation meetings and the pattern usually is that a person less comfortable with the product or knows less tends to estimate higher to accommodate for any surprises versus a person who knows the product better or is a subject matter expert. What do you tell the team in such situations? Or what is the right way to estimate when you have a team with mixed experience levels.

Avienaash Shiralige February 8, 2015 at 9:57 pm

This do happen often. Discussions between them bit more in detail is needed to come to a shared understanding. That is the real goal of this poker estimation. You can also schedule some knowledge sharing sessions or pair programming to transfer knowledge. Pair the expert with the less experience person on complex pieces or any area of the product where only senior folks on the team have code/domain knowledge.

If the person is new to the team, then I have asked few times to be part of this estimation and discussions, but not estimate say for couple of such sessions. Hope this helps.


Avienaash Shiralige March 8, 2015 at 12:08 pm

Poker planning bring all such missing information to the table for discussion. Read my earlier posts on using story points to even out such differences. Even team finally agrees to go with higher number, scrum focus on honesty here. Say the team finished that story well before time, then they should pick-up something more. In retro they should bring this point for conversation.

nachiket shukla February 11, 2015 at 3:02 pm

Found someone using this article verbatim on other site without crediting the author….

Avienaash Shiralige March 8, 2015 at 12:04 pm

Yeah I just saw that. bad.

Bala June 20, 2015 at 9:31 pm

Yes. I really felt bad as that person has not even mentioned about from where he has copied.
Avienaash should complain to Scrum Alliance.

Melissa February 27, 2015 at 2:13 am

Hi Avienaash,
Asking for your opinion. Obviously during a sprint, new projects or issues come up that need to be added to a sprint. In my opinion, they need to be estimated before being added to the sprint. A person on my team disagrees and wants to retroactively assign points to it. I don’t feel that this is correct and completely takes away from the estimation process. I’m thinking that they don’t know how much work is going to be involved. In which case maybe another ticket should be added for R&D. Thoughts?

Avienaash Shiralige March 9, 2015 at 11:43 pm

I agree with your thoughts. Even I will take the same route. Always estimate it before taking it on. Sometimes if estimate is very high then I have seen PO’s dropping that story or adding it into next sprint. If any story is not estimable, then divide that into R&D or a POC story and implementation in a second story. Do just enough POC on it so that you have sufficient knowledge to estimate it with reasonable confidence.

Anusha July 15, 2015 at 3:50 pm


While estimating the tasks in hours- should we take into consideration the number of people who ‘ll be working on that particular task. For example we may have a task which might take about 15-20 hours to finish. But if 2 people work on it- then it might be completed in 10 hours (assuming) . So while estimating- do we take into consideration the number of people who would be working on it- or do we just go with “how long will one person take to finish this task” estimate?

Pujan July 19, 2017 at 4:32 pm

All 8 points are making sense, gradually team will be expert in relative estimation.

Mayur September 11, 2017 at 6:27 pm

How to understand the complexity of User Story and subtasks.

Comments on this entry are closed.

{ 6 trackbacks }

Previous post:

Next post: