Story points represent the relative sizing of the user story. It is a unit of estimation used by Agile teams to estimate User Stories.
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.
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.
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.
STORY ESTIMATION PLANNING POKER
Agile teams often use ‘estimating poker,’ which combines expert opinion, analogy, and disaggregation to create quick but reliable estimates. Disaggregation refers to splitting a story or features into smaller, easier to estimate pieces. (Note that there are a number of other methods used as well.) The rules of estimating poker are:
Participants include all team members.
Each estimator is given a deck of cards with 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, and, ?
The PO participates but does not estimate.
The Scrum Master participates but does not estimate, unless they are doing actual development work.
For each backlog item to be estimated, the PO reads the description of the story.
Questions are asked and answered.
Each estimator privately selects an estimating card representing his or her estimate.
All cards are turned over at the same time to avoid bias and to make all estimates visible.
High and low estimators explain their estimates.
After a discussion, each estimator re-estimates by selecting a card.
The estimates will likely converge. If not, the process is repeated.
Some amount of preliminary design discussion is appropriate. However, spending too much time on design discussions is often wasted effort. The real value of estimating poker is to come to an agreement on the scope of a story. It’s also fun!
STORY ESTIMATION ROCK, PAPER, SCISSORS
The team agrees on hand signals for the work item scale.
The product owner reviews the first work item, providing background, persona/customer details and how it fits into the overall goal.
The team discusses the work item.
The meeting facilitator says something like ”1, 2, 3, throw” or some other method to get all the hand signals displayed at the same time.
The team member shows their hand signal. Differences in the estimates are discussed and agreement is reached.
The meeting facilitator groups the estimate-complete work items by estimate value.
After all estimates are complete the team discusses each group and moves the work items to the correct group if necessary.
The product owner decides whether to accept the work items at that level.
The team agrees on how to handle items that are too large for the time boundary.
Items are categorized into t-shirt sizes: XS, S, M, L, XL. The sizes can, if needed, be given numerical values after the estimation is done. This is a very informal technique, and can be used quickly with a large number of items. Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate.