The described approach below gives you an indication of how the estimations can be achieved using Planning Poker®. Nevertheless, it is crucial to understand that every team is slightly different from each other and you might experiment and adapt the rules and the process to figure out the solution that works best for your team.
How Planning Poker® works?
When your team plays Planning Poker®, you rely on the expertise of the team members who are involved, and they provide their individual opinion on the user story at hand.
This technique helps the team to approximate the effort or complexity of a task and ensure that everyone is on the same page. The team can also resolve a different understanding of how to implement the story.
If anyone from the group chooses a different card, then there must most certainly be a debate and even arguments in some cases until the team has a consensus about their implementation.
To play Planning Poker®, you need the following prerequisites.
- A scrum team that understands how Planning Poker® works
- A group of developers that agreed on the stories described by the product owner in advance
- A deck of Planning Poker® Cards
- An agreement of the team if they estimate the relative effort or complexity
- An understanding of what the agreed reference story is and how many points that are assigned to it
- The Product Owner is reachable in case of inquiries or on debates splitting up stories
Deal the cards
Make sure every team member has a set of cards.
These cards usually have the following values and meanings:
Agree on the reference story
Especially when you play Planning Poker® the first time. It is helpful to remember a story or task the team has finished recently and agree on a value.
This story will act as a “reference story” to estimate relatively to it.
Make sure, that you do not choose a too small or a too big story since this reference story should remain for more than just the next sprint to have a meaningful burndown chart and velocity over the whole project.
You can also skip defining a reference story and entirely rely on the gut feeling of your team. This works out better than it sounds at first sight.
Story by story
Now the team can open the first user story - ideally presented on a big screen or on a sticky visible to everyone.
Next, ensure that everyone understands “what” has to be done in this user story. This step is important and should be confirmed by every team member by a small sign (e.g., “thumbs up”).
Then ask the second question to the team if everyone has an idea in his/her mind of how to tackle the story. (Do not speak up loud or debate at this stage except when at least one developer has difficulties to come up with a solution or he/she has any uncertainties)
Now everyone in the development team (neither the Product Owner, nor the Scrum Master) picks a card silently and invisible to the other team members.
When everyone has prepared a card you turn it around simultaneously and show it to the team.
Now there can be the following outcomes:
…when everyone picked the same card
Perfect. Enter the agreed story points to the story and take the next story.
…when different card values are shown (no ? or “Coffee Break”)
This is the interesting part. It’s debate time. Never! Really never skip this part and just pick an average…
Set the stage for the debate: - Elect the most qualified person with the lowest number - Elect the most qualified person with the highest number - The team only elect 2 people in total, even then, when the highest or lowest number has been shown more than once
Now, the developer that represents the highest number starts explaining the thoughts behind the chosen card. - There is no discussion allowed at this stage.
After that, the developer representing the lowest value explains the thoughts behind his/her pick.
During this phase, the whole group gains insights about what others were thinking and can silently compare them with their own minds.
Without any further discussions, the next round of estimation takes place. Influenced by the prior explanations, everyone is allowed to change their mind and pick another card then in the round before.
Continue this iteration until everyone agrees on the same number.
…when a “?” card is shown up
Give this person a voice to post his/her concerns. And try to clarify it.
…when a “Coffe Break” card is shown up
Decide as a team whether or not and when you do a coffee break.
However the team decides, you should consider that one of your teammates is tired and would be happy taking a break to reshape his focus.
In this section, we would like to enlight some unusual scenarios that might happen and provide our recommendations.
One point difference
If there is just one point difference between the highest and the lowest card. You can also quickly agree on one of the value.
On the long run, this single point should not have any significant impact on velocity, nor productivity.
Distributions with a reasonable huge gap
Sometimes one part of the group has a solution that is more complex than the other part of the group.
This is a clear sign of having not the same understanding of “What” has to be done priorly described.
It’s recommended to involve the Product Owner and discuss the minimally viable solution this story can be achieved.
Remember, simplicity is king! Not in favor of technical debt. But try to avoid adding bells and whistles in the first iteration. You can always do this in another iteration when the priority allows it to do so.
Clarify and agree with the team on one of the implementation and re-estimate with the newly gained insights.
Someone refuses to adjust
Assume the team generally has consented, but just a few or even worse only one person refuses to find a compromise after several rounds.
In such a case it is helpful to remind everyone that this is an estimation. An estimation always includes uncertainties.
If this does not help, a more experienced developer having picked another number that is very confident that, they over or underestimates the story by far, can offer a pair-programming session to fulfill the story.
Also, remember the reference story, or a story you have just agreed on and bring this story into a relation to resolve the situation.
Leftover story from the previous sprint
Something it happens that the team could not have finished a story of the previous sprint, but has already started or is almost finished.
Such a story usually has some story points assigned to it. What to do now?
In this case, we need to remember that the velocity is an essential measurement in the long run. The story points can only be credited to the sprint where the story is considered as done. Therefore the previous sprint did not get any points for the effort invested until now. This means you should not adjust the estimations and lower the number for the sprint ahead of you. Take the story points in the new sprint to ensure a correct average on the long run.
Lack of experience in a particular topic
When there is a lack of experience for a particular topic by someone or a part in the team. You should estimate as if you would have the know-how.
“Lack of know-how does not increase the complexity of the story itself.”
Too many uncertainties with significant impacts
When there are too many uncertainties, consider planning a Spike that blocks this story and re-estimate the story afterward.
A Spike is an advanced Time-Boxed slot within the sprint where the team collects the know-how to achieve the story.
Do’s & Dont’s
Don’t work with margins
A less experienced or less stable team tend to create a margin on a task to compensate uncertainties in this or other stories by estimating a higher number than necessary.
Never do this! It’s ok, to take the wrong estimation from time to time. You also have to consider that you might achieve other stories with less complexity than you thought before.
The goal behind story points is to achieve a reliable and consistent velocity. Not to collect points.
Don’t compare with other teams
Estimations and story points cannot be compared with other teams. Every team agreed on its own reference story and might have a different range of cards they use.
Do Reflect after the sprint
To continuously improve your accuracy and reliability, consider reflecting your most under- or overestimated stories in the retrospective. And adapt in the next planning.
Accept flaws from teammates
Not everyone is an expert in all domains. Establish a respectful discussion culture while estimating and debating.
It’s the worst thing when someone does not have the heart to give any inputs anymore. You would most probably block an essential contribution in the future.
Let juniors joining the debates
Create some diversity when electing the persons that debates. Give junior developers a voice to figure out what they care about and how far they are in their personal development.
Giving them a helping hand by suggesting a pair programming session when you can help out to close a knowledge gap on a particular story. It’s a free lunch when it comes to improving the skills in the team continuously.
Stop when you have estimated enough points reachable in one sprint
Calculate your expected velocity before you start with the estimations. This way you can stop after a reasonable time or provide a signal to your Product Owner to provide you with more stories if it is significantly low.
To prepare a sprint backlog which is well-balanced, it is recommended to have the PO as a passive member in the room when you play Planning Poker®. This way, the Product Owner obtains a gut-feeling on which stories are involved and which aren’t.
Prepared sprint backlog refinements during the sprint for the next sprint is a handy technique to provide a more accurate number of backlog items. Backlog refinements can be achieved by only a part of the team or a single mature developer together with the Product Owner.
Don’t change estimations during the sprint
Regardless of figuring out that a story point estimation was wrong when you have worked on a story, never change the opinions during the sprint.
Instead, bring write it down and bring it up in the next retrospective so the team can learn and improve.