Agile emphasis to estimate a story in Story Point instead of hours.
What is a Story Point?
Story points represent the relative sizing of the user story. It is a unit of estimation used by Agile teams to estimate User Stories.
When the product owner wants some features to be developed he/she desires to know how soon the team can complete the features and how many resources it will take to complete the work. From the developer’s perspective, it’s next to impossible to predict the exact time in which he/she can complete the work. The person can, however, give a rough estimate in terms of how much time it might take to complete the work. Note that instead of “will” the developer chose to use “might” because he/she is not absolutely “sure” about the time factor but “feels” it might take that much time. This is user story estimation in a nutshell.
You don’t give an exact number explaining how complex the story is and how long it’ll take to develop – you give a rough “estimate”.
We are good at comparing size, so estimating a story using Fibonacci series sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, and 100) gives more clarity of its complexity and relative sizing in terms of development. It is helpful to have a set of stories nearby to make a comparison and recommendation to set priority.
Here are the examples of relative sizing and its estimation points to develop the following vehicles:
Consider the following factors while estimating stories
- Complexity: Consider the complexity of the story.
- Risk: Consider the team’s inexperience with developing this story.
- Implementation: Consider the implementation factors.
- Deployment: Consider the deployment requirements.
- Interdependencies: Consider other outside issues.
Who should be involved in story Point estimation?
All team members who are responsible for getting a story done should ideally be part of the estimation.
Advantages of using story points for estimating work
- Story points are a measure of relative size and complexity.
- Story points are unitless, meaning as a scale, they are only valuable to compare against each other within the same team.
- Estimating in story points allows/encourages everyone, including business people to participate in the estimation process (using Planning Poker).
- Estimating in story points is fast and easy.
- Story points initiate high-level discussions about everything that is involved in a project.
- Earned points can be used to generate the teams’ velocity which can be used to predict future work capacity.
Steps to estimate stories
For each story to be sized, do the following as a team (Product Owner, Scrum master & Team member).
1. Identify base stories
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 story is the same among everyone on the team. The team should be confident of this base story.
2. Talk through the detailed requirements
Product Owner will answer questions and provide the explanation about what exactly this story entails.
3. Discuss and note down points
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. Raise questions if any
During the discussion, the question may arise and must be clarified at the same time, Such as:
-
-
- Requirement: Any doubt about story requirement? Raise an alert. Ask product owner to give more clarity.
- Technical Feasibility: Can a story be delivered using current technology? Any unforeseen technical challenges must be surfaced.
- Acceptance Criteria: Team must clarify the checklist to be fulfilled to mark the story as accepted.
- Dependency: Does this story have external dependencies? If yes, that must be understood and resolved quickly.
- Expertise: Do we have enough skills to deliver the story? The team must have internal skills to deliver story otherwise delivery might be delayed or not done properly.
-
5. Agree upon estimated size
Every team members must agree upon estimated size decided on a story.