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 development 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 nut shell.
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”.
How do we estimate in points?
We are good at comparing size, so estimating a story using fibonacci series sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, 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 comparison and recommendation to set priority
Here are the examples of relative sizing and its estimation points to develop following automobiles:
You should consider following factors while estimating a user 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?
The team which is responsible for getting a story done should ideally be part of the estimation. If the team has QAs to test stories and do test automation, they should also be part of the estimation exercise along with the developers. The QAs should be able to call out if story has less development effort and more testing effort involved. For example building a customer search screen might be a 5 point story, supporting it on two new browsers might be a 1 point development effort but a lot more from a testing perspective. In this scenario QAs who are part of the estimation exercise should call this out and size the story to reflect the adequate testing effort which in this example might be 2 points.
Advantages of using story points for estimating work
- Story points are a measure of relative size and complexity
- Story points are unit less, 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
7 steps to estimate stories successfully
For each story to be sized, do the following as a team (Product Owner, Core Scrum team including developers, testers and scrum master).
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 story 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.
- Design: What will we have to learn before we can start work on this story?
- Coding: How much code will need to be written for this story? Have we written similar code before?
- Unit Testing: Will any special setup (e.g., mock objects) be required to unit test this story?
- Acceptance: Testing How much work is involved in helping the customer to automate the acceptance tests for this story?
- Integration Points: Does this story have external dependencies?
- 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.
In story point estimates, it does not matter if your estimates are correct or incorrect as long as you are consistent.