Planning poker is one tool used in agile. The reason it is useful is that it can help the team decide how many points to assign to a particular story or task. This helps facilitate endless discussions.
The method described below shows you how to use Planning Poker to make estimates. However, it is important to understand that each team differs slightly from the other. You can try to adjust the rules and processes to find the solution that works best for your team.
How does planning poker work?
When your team plays Planning Poker, you rely on the expertise of the team members involved, who can provide personal opinions on user stories.
This technique can help the team get closer to the workload or complexity of the task and ensure that everyone agrees.
If someone in the group chooses a different card, then sometimes, it definitely needed a debate or even an argument until the team reaches a consensus on its implementation.
The prerequisites:
To play Planning Poker, you must meet the following requirements:
- The Scrum team must understand how Planning Poker works
- A group of developers must agree in advance with the story described by the product owner
- Plan a poker game
- If they estimate the workload or relative complexity, the team must agree
- Understand what the agreed-upon basic story is and how many points are scored
- In the case of surveys or shared discussions, the Product Owner can be contacted
How to play:
Hand out cards:
Make sure each team member has a set of cards.
These cards usually have numerical values, and their meanings are:
0: A value of zero means that the story can be completed performing no operations. It is mainly used when the deployment is suspended.
0.5: Not zero, but almost a piece of cake that blind people can do.
1: This is a short story with no complexity or effort.
2: Double the meaning of 1.
3: A little more than 2.
5: This is an interesting card. It takes brains and effort to make this story happen. Widely used when the story gets serious.
8: Much more than 5, but still controllable.
13: This number shows that the user's story is on the cutting edge, becoming too complicated to be considered a single story. Consider splitting the story.
20: This card primarily expresses some desperation by team members. As a team, you should consider splitting the story.
40: To a large extent, these cards simply express the desperation of the team members. As a team, you should consider splitting the story.
100: To a large extent, these cards simply express some desperation by the team members. As a team, you should consider splitting the story.
?: A question mark card appears, and the developer does not know how to estimate the story.
☕️: Planning a sprint can be exhausting. This card shows that the team member is asking for an abrupt break.
Agree to refer to the story:
Especially when you are playing Planning Poker for the first time. It helps to remember the story or task the team recently completed and agrees on the value.
This story will be used as a reference story for the estimate.
Be sure not to choose a story that is too small or too large, as this baseline story should last longer than the next sprint in order to achieve a meaningful burn-down graph and velocity throughout the project.
You can also ignore the definition of a story and rely entirely on the intuition of your team. The effect is better than at first glance.
Story by story:
Now the team can open the first user story, preferably on a big screen or on a sticker that everyone can see.
Next, make sure that everyone understands what needs to be done in this user story. This step is very important and each team member should use a small sign (like "thumbs up") to confirm.
Next, ask the team the second question, if everyone knows how to handle this story. (Don't talk much or argue at this point, unless at least one developer is struggling to find a solution or is unsure)
Estimates:
Now, everyone on the development team (whether it's the product owner or the Scrum Master) silently picks a card that is not visible to other team members.
When everyone has prepared the card, you turn it over and show it to the team at the same time.
The following results are then possible:
...When everyone chooses the same card:
Enter the agreed story point in the story and move on to the next story.
...When different card values are displayed (? or "coffee break")
This is the interesting part. Now it's time for the debate. Never really skip this part, just pick an average...
The basis for preparing the debate:
- Choose the most qualified person with the fewest numbers
- Select the most qualified person with the most numbers
- The team selects only 2 people, even if the highest or lowest number has been displayed several times
Now the developers with higher numbers explain the idea behind the selected card. No discussion is allowed at this point.
Later, the developers representing the lowest value explained the ideas behind their choices.
The entire group understands each other's ideas and can silently compare them with their own.
Without further discussion, move on to the next round of estimation. Affected by the initial explanation, everyone can change their minds, choose another card, and then go back to the previous round.
Continue this iteration until everyone agrees on the same number.
...When a "?" is displayed
Let that person express his or her concerns. And try to clarify it.
...When the "coffee break" card is displayed
As a team, decide if and when to take a coffee break.
Whatever the team decides, consider that one of your teammates is tired and is happy to take a break to refocus their attention.
What to do and what not to do:
- Don't work with margins:
Inexperienced or unsteady teams slack off on the task to compensate for the uncertainty of this or other stories by estimating a higher number than necessary.
Never do this! It is normal to make bad guesses from time to time. You should also consider that you can create other stories with less complexity than you previously thought.
The goal behind the story point is to achieve a reliable and consistent speed. Don't collect points.
- Don't compare with other teams:
Estimates and story points cannot be compared with other teams. Each team agrees with their own reference story and may use a different range of cards.
- Post-Sprint Reflection:
In order to continually improve your accuracy and reliability, please consider reviewing your most underestimated or overestimated stories. And make adjustments in the next plan.
- Accept teammate error:
Not everyone is an expert in every area. Establish a culture of respect for discussion while valuing and debating.
It's the worst thing ever when someone doesn't have the heart to give their opinion. You risk blocking important input in the future.
- Involve elementary students in the debate:
Create some diversity when electing debaters. Give junior developers a voice in understanding what is important to them and their progress in personal development.
Where you can help fill in gaps in knowledge about a particular story, help them by suggesting pair programming sessions. In terms of continuous improvement of team skills, this is a free lunch.
- Stop when you feel there are enough achievable points in the sprint:
Calculate your forecast speed before you start estimating. That way, you can stop after a reasonable amount of time or send a signal to your product manager to provide more stories when it's significantly lower.
In order to prepare for a balanced sprint backlog, it is recommended that PO be the passive member of the room when you play Planning Poker. This way, the Product Owner can intuitively understand which stories are involved and which are not.
Preparing for the backlog sprint during the next sprint is a handy technique for providing a more accurate number of backlog items. Backlog improvements can only be done by a part of the team or by a single mature developer of the product owner.
- Do not change the estimate during the sprint:
Whether the story point estimate is incorrect when you process the story, never change your mind during the sprint.
Instead, write it down and present it in the next retrospective so the team can learn and improve.
