How to estimate a user story

In the Agile and Scrum projects, Scrum Teams use quite a few different methods for estimating any piece of work. In this article, I will be discussing few of the most popular methods.

Ideal Time:

The Ideal Time is probably still the most commonly used technique for estimating any piece of work. It is simple, you look at the requirement and then think how long you think it will take to complete this piece of the work. The Ideal Time estimation is heavy used in the waterfall projects.
The advantages of Idea Time estimation are:

1. Simple to understand and use.
2. In the beginning, the teams will be more comfortable using the Ideal time than story points.
3.  Stakeholder and other external people can easily understand the estimate.

Disadvantage:

1. Each part of the team will give estimate independently without taking into account the impact on the other functions within the team. The developer will give the estimate without considering the impact on tester and tester will give the estimate without talk to the developers.
2. Confusion between ideal time and real time. If the team has given the estimate of 5 ideals day, then management might hold the team accountable to completing the task within five days. Whereas their difference in ideal time and real time. The estimate of 5 days ideal time means that it would take the developers entire time doing nothing but working on this for five days. Whereas in reality, those five days effort will be done over many more days because ideal time does not take into consideration, all the distraction and meeting that team members have every day. In the days when I use to use ideal time, I used to only calculate 6 hours of the working day toward the development task on the project.

T-Shirts sizing

The T-shirt sizing is simply estimation technique that is very easy to grasp. This technique is useful for Scrum teams that are new to Scrum and haven’t been involved in a group estimation session or for the Scrum team that get too much hung up on what numeric value to give to each story. The way t-shirt sizing work is that you look at each story in turn and try to see if the story is XS, S, M, L, XL. It is beneficial for the team that first time they have an estimation session that they put all the stories in the order of size, largest to smallest. Then the team choose a story that they think is of a medium size, this gives the team a baseline to use for all the other stories.
The most common downside to t-shirt sizing is that you can’t go over to your senior management and tell them that in this sprint you have done three medium, four large and one extra-large stories because this wouldn’t make much sense to them.
You can get your team to become more creative and expand this estimation technique to do things like estimating in Sand bucket sizes.

Story points

The Story point estimation is becoming rapidly popular in the Scrum teams. in the Story point estimation, we use poker cards with rounded Fibonacci sequence on (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) and we use the planning poker game to estimate any given user story.
In the Story point estimation, the whole Scrum team must take part in the planning poker game, and the team try to estimate how much effort it to entirely get the story done (to the Definition of Done). The Scrum Team must consider the following when estimating any story:

• The amount of work to doThe complexity of the work
• The complexity of the workAny risk or uncertainty in doing the work
• Any risk or uncertainty in doing the work

The way it works is that the product owner explains the user story and team members are free to ask any question regarding the user story. When everyone has asked the questions, the product owner will ask all the team members to hold up the planning poker cards with the story size at once.

The way it works is that the product owner explains the user story and team members are free to ask any question regarding the user story. When everyone has asked the questions, the product owner will ask all the team members to hold up the planning poker cards with the story size at once.
Product Owner or Scrum Master (depending on who is leading the estimation session) will ask the team member with the smallest story point to explain why he/she thinks the story the story is so small. Then the Scrum Master would ask the team member will the highest story point to explain why the story is so big. This way all the assumption regarding the story are clarified and team start to form a common understanding of the user story. This would follow another planning poker estimation where team hold up the poker card for this story followed up another discussion between the highest and smallest card holders. Personally, I try to limit the estimation and discussion of the story to three rounds.
By going through this process, you can easily clarify assumption and get the whole team involved in quickly. You might find that a story might be very easy to develop but difficult to test for the tester, and when you use the planning poker the dev will hold smaller story point, and tester would be holding the poker cards with very high numbers. In the discussion, it would become clear how much effort it is to get each story Done.

No estimates

Estimation and planning poker takes time and energy that the team could be spending on developing the new features. Also, the estimates are still an estimate, and the team would only fully know how much effort it is to complete any story till it is fully complete. Based on the fact like these are new idea was born in the Agile world that we would get rid of estimates altogether.

The best resource for estimation, that I have found useful till today is Mike Cohn’s book called “Agile Estimating and Planning ”