Agile Estimation techniques:

1) Planning Poker:

• The below figure shows the poker cards available to estimate the user stories.
• Before starting Planning Poker, select one story which is a reference story (from the current backlog or that we have done earlier).
• In this technique team, Scrum Master, Product Owner will sit around the table (Figure is shown below) for the planning poker session.
• Each team member will have a set of Planning Poker cards of values (0,.5,1,2,3,5,8,13,20,40 and 100) these represent story points in which team estimates.
• At the start of the session, the product owner will read the user story aloud, describing all its features and requirements.
• Then the team will estimate with the number mentioned on cards and show it to everyone. If all have given the same value then that will become the final estimate.
• If the values are different then estimators giving the highest and lowest values explain their opinions and why they chose this value, until a final consensus is reached.
• A good technique for a small number of items in a small team
• Till the final consensus is reached team will have complete clarity on the user story.
• If the estimator doesn’t have any idea or couldn’t estimate can show (?) also.
• If the user story is estimated as above 20 considered as Epic which needs further break down into smaller user stories.
• Story point estimated as 4 story points is of double the effort, time and complexity than a story with 2 story points.

2) T-Shirt Sizes:

• Items are estimated as T-shirt sizes XS (Extra Small), S (Small), M(Medium), L(Large), XL (Extra Large), XXL (Double XL)
• PERFECT technique to give a rough estimate of the large backlog items.
• Useful and quick estimation needs to be done.
• The disadvantage is that L to someone may seem XL to someone. After discussion and resolving the mismatched, consensus can be reached to get the final estimate.

3) Dot Voting:

• This is basically a ranking method to decide the order of the Product Backlog from the highest to the lowest priority stories.
• To start this, post all the user stories along with their descriptions on the wall
• All the stakeholders are given 4 to 5 dots (mostly color pencil or pens).
• They are asked to give their votes on the user stories they prefer.
• The one which receives the highest number of votes is considered the highest priority user story.

4) Bucket System

• It is a good technique where a large number of items needs to be estimated with a large number of estimators.
• Different buckets are CREATED with values same as that Poker cards.
• These are sequentially arranged on the table.
• The stories need to be placed on these values where the estimators find it suitable.
• Before placing the user story, estimators must have a clear understanding of it. Discuss the complete requirements and feature details.
• At last sanity check is performed by all the participants. If any participant finds a wrong bucket assigned to an item then they can BRING it to notice and can be discussed until final consensus is reached.

 5) Large/Uncertain/Small

• This is a rough version and is the simplification of Bucket system where there are only 3 sizes. Large, Small, Uncertain.
• The estimators are asked to place the items in one of the categories. First, the simpler ones are chosen and placed in the Large and Small category after that complex are chosen and placed.
• A good technique when there are comparable items in the backlog.

Story points are helpful because they allow team members who perform at different speeds to COMMUNICATE and estimate collaboratively.

When story points equated to hours, team members can no longer do this, as the time taken by one person compared to another person is different. One can finish the task in 3 hours and the other in 6 hours. Our aim is to estimate the user story, not to deep dive into why one person took 3 and another 6. If someone instructs team members that one point is equal to 8 hours, the benefits of estimating in an abstract but relatively meaningful unit like story points are lost.

Suppose for some reason you have tracked how long every one-story-point story took to develop for a given team. If you graphed that data you would have something that would look like this:

This shows that some stories took more time than others and some stories took less time, but overall the amount of time spent on your one-point stories takes on the shape of the familiar normal distribution.

Instead of looking at a User Story and estimating it in hours, teams consider only how much effort a User Story will require, relative to other User Stories.

“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide broad-brush relative estimates of effort for completing requirements STATED in User Stories “

Story points further used to calculate the velocity of the sprint which is very helpful to predict the release dates.