Home > Agile > Agile estimation and Story points

Agile estimation and Story points

1) What is story points in Agile
Story point is a unit used in agile process which estimates the efforts for implementing a complete feature considering actual efforts, risk involved, uncertainties may occur and complexities of the implementation.
The story point actually defines the difficulty level to achieve the goal.
The main goal to use story points in the estimation process is to address the underestimation problem. The story point can indicate the user the difficulty level of the story.
Since story points are not the actual hours, teams will able to think in different aspects that  how much effort a story will require in comparison to other stories in the backlog list.

2) What are available story points 
The story points are just the numbers which do not have measurement units. 
Usually, Story Points are assigned from smallest to biggest story with the point sequence. The smallest not necessarily the easiest story to work.
Frequently used scaling measures for a story points are as follows-
A. 1,2,4,8,16
B. Also the story points are used as we use in sizing the T-shirt- X-Small, Small, Medium, Large, Extra-Large 
C. Fibonacci sequence: 1,2,3,5,8,13,21

3) Is it possible to related story points with hours
The story points are not actual time, but the relative measure to track the efforts required for the story. Basically, one cannot relate story points to hours, otherwise the importance of estimating the story on efforts will lose.

4) How many story points should be in the sprints
In reality a sprint should not measure by story points, but management should decide how many sprints are required to complete all the list of backlog items estimated with story points
Hence manager can get the overview of the project to be completed.

5) Example of story points
Consider if a person want to travel from India to US and have lists of travel options like bicycle, bike, car, bus, train and aeroplane and asked him to line up them based on time of travel could be taken from fast to slow. In this case aeroplane will take the least time to travel.
Once the same is lined them up by travelling time you can give any number sequence. Or can use Fibonacci sequence 1,2,3,5,8,13,21 in which 13,21 numbers shows the more complexity, hence In this case bicycle and bike will take more or really long time to travel than aeroplane. This is not related to the exaxt time of travel, but to understand the complexities of travel time.

6) How to estimate Research Stories?
A. Decide a base story –  from a current/on going sprint which is already completed or done. The understanding of the base story should be same for all the team members. The base story should be relative to the other backlogs stories around which the new sprint needs to be estimated.
B. Discussion on requirement – The team will discuss the requirement and raise the queries related to the requirement, Technical issues, Acceptance criteria, External dependencies, Skill sets availability. The product owner will address the queries of the team member. The scrum master will note down all the details of the discussion and share the important points to the team.
C. Planning poker – Once the discussion is over, the team plays “Planning poker” to estimate the work. Planning poker is an estimation technique to estimate the backlog items. 
i. The team chose a story to be estimated 
ii. Each team member gets a set of cards with numbers;
iii. The team member individually and privately selects a card which represents the estimate for the story.
iv. Once everyone has done the estimates for the story, the team discloses the number at a time. If everyone has the same number (same estimates) team agrees and move on to next backlog item to estimate. The process repeats for the next story and if the estimate of the team members varies then the team discuss the points of difference and come to a conclusion to freeze the estimate. 
In a similar way all the stories got estimated by numbers.

D. Convert number to hour base estimate – Converting numbers into hour base estimates is difficult for the 1st sprint. In first sprint the scrum master and product owner gauge the pace of the team to complete the sprint. As the 1st sprint ends the scrum master/product owner can estimate how many story points are required to complete a sprint to the team. After all backlog items got estimated with story points; the scrum master and product owner collectively decide how many sprints needed to complete the project and finalize the calendar date as the delivery date. 

7) Benefits as Story points
1. The proper estimation done for the stories, sprint along with an entire project.
2. The skill to estimate the task properly improves for each team member despite of experience and the  level of expertises.
3. The pace of the project can be tracked and schedule of the project can be reviewed time and again as required
4. The unclear demand, dependencies, uncertainties, expertise required can be spotted before hands, which make the project cost effectiveness.
5. The understanding of the requirement of the entire team will be same.
6. Time pressure of achieving the deadlines reduces.

8) Common mistake while using story points
1. Story point is effort based estimation technique. Efforts are based on risks, uncertainty and complexities of the story. Estimating the efforts considering the only complexity will lead to wrong estimations.
2. Converting story points into actual hours will defeat the benefit of the story point technique
3. If estimates and delivery are not on track adjusting the estimates 
4. Misunderstanding that reference backlog items can not be changed
5. Not splitting the stories properly
6. Not defining the acceptance criteria for the stories
7. Trying to achieve the technical quality, but not the business requirement
8. Bugs are not considered while estimations using the story point technique

9) Can we use points to estimate bugs?
The story points can not use to  estimate the bug fixing and retesting of fixed bugs. The bugs are considered as it is part of work which needs to be completed by the team. The efforts to fix the bugs and retesting of them should have been considered while initial estimations. 

This Article is TAGGED in , . BOOKMARK THE permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">