There is a user-story estimation method that is very popular in the Scrum universe: Planning Poker; it’s also called scrum poker. We will discover how this famous planning poker works.
When to do poker planning?
Some people estimate their user-story during the Sprint Planning but it is recommended to make a Product Backlog Refinement to refine the user-stories.
In a nutshell, the Product Backlog Refinement (Grooming) is a Scrum ceremony that we usually do once a week to refine user-stories and estimate them. The Sprint Planning will be better because the Product Owner will already know exactly what he will put in the Sprint that starts.
Here is an article on the subject if you want to know more about the Product Backlog Refinement (Grooming): Product Backlog Refinement
Additional material needed for poker planning
To estimate your user-stories with the Planning Poker, you will need planning poker cards of this type:
You will also find applications on your mobile phones by searching: Planning Poker.
Each developer will have his game (or application) card in order to participate in the votes.
We start the planning poker session
The Product Owner will present a user-story that he has completely finished (according to the definition of ready) to the developers so that they can estimate it. It’s ideal to also present the content of it by projecting the software used.
After the concrete explanation, the developers will be able to ask questions if the user-story is not clear enough; the Product Owner will answer questions and write the answers to complete the user-story.
Incomplete
If the user-story is incomplete and doesn’t allow the developers to estimate it, the Product Owner will have to keep his user-story, complete it and come back with it at the next session.
Do not estimate a user story that is incomplete or if the Product Owner can’t answer at all questions. It’s better to delay the delivery of a feature than to disrupt the entire production chain.
Complete
The developers will vote with their cards as soon as they have no more questions about the user-story.
To vote, each developer will choose a story point of the user-story. The developers will have to ask the question: “What is the story point in my opinion to achieve this user-story?”.
Concept of story point in planning poker
The story point of a user story (or a technical task) will include different notions that developers will have to take into account to estimate it:
- the effort to do to develop the request
- the difficulty (complexity) that may be the request
- the risks that we imagine to meet during the development of the US
- any unknowns existing at the time of the estimation
- potential dependencies with external elements
We must accept that the story point is an “abstract” notion that can not be compared to a number of man days. However, we could do predictability in the future.
Yes, the story point takes a notion of time contrary at the ideas that we can read sometimes. But its estimation isn’t based on it and this notion of time isn’t materialized by 1 story point = 1 day.
Utiliser la suite de Fibonacci en planning poker
To rating the story point, we will use the suite of Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21 … In general, most teams that make Sprint of two weeks use sequence 1, 2, 3, 5, 8 and 13; these teams estimate that 21 would be the rating to say that the user-story is too big and that the Product Owner have to split it.
This suite was used because higher rates suggest a higher uncertainty. When a request is very complex, needless to choose between 12 and 13, it would not make much sense; We prefer to say that it’s 13.
Voting process in planning poker
Now, the planning poker session takes place between the developers.
Each developer will choose its story point in secret, and all developers will show their rating to the entire team at the same time.
Here are the possible cases and the results of them.
Perfect osmosis during poker planning
All participants rate the same story point, so we validate this story point 1 on the user-story.
Consensus 1 during poker planning
All participants don’t rate the same thing but the gap remains correct (no more than 2 rows of difference between the smallest story point and the largest). So, we will validate the story point 5.
Consensus 2 during poker planning
planning poker consensus – poker planningAll participants don’t rate the same thing but the difference remains correct (only 1 rank of difference between the smallest story point and the largest). So we will validate the story point 5 that is the highest rating even if only 1 participant rate for this story point.
To rate again
All participants don’t rate the same thing and the gap is too big. We will ask the developers to discuss together in order to find a logical consensus. The developer who finds the request complexed can be helped if he will take the user-story; so he will lower the story point that he had estimated. Sometimes the discussion will also show that the user-story was perhaps not so well understood and that the difficulty had been underestimated.
After a good discussion, the developers will review the story point of the user-story.
Conclusion Planning Poker
The product owner will purpose the exercise of planning poker on all user-stories of his backlog that they will develop soon. He will prepare the next Sprint that he will purpose to the developers.
keywords: poker planning
4 Trackbacks / Pingbacks