Last week we talked about estimates always being wrong using relative sizing. Planning Poker is a technique which gamifies this concept. And no, this is nothing like Strip Poker 😜
The game may be moderated by the Scrum Master, the Product Manager or anyone else.
Essentially you get the development team into a room and everyone sit around a table.
Each team member is given a set of cards, which has different sizes on them:
XX Small
X Small
Small
Medium
Large
X Large
XX Large
So if you have 5 members in the team, you would have 35 cards - one of each size for each member.
Then you take out the user story one by one, in the sequence in which they need to be executed. Ideally the team would be familiar with the user stories because they would have created them as part of the elaboration process (Check out earlier video - Plan before you start)
When the first user story is in play, each players thinks about it for a minute and takes out a size a card which he/ she thinks best represents the size of the user story. They keep this card upside down on the table, so that nobody else can see what size they selected.
Once all players have put a card on the table, everyone reveals their selection.
There are typically 3 scenarios:
Everyone has selected the exact same size
The sizes within one size of each other. All are either medium or large. You can either go with the majority/ the larger size, whichever feels more appropriate according to the team
There is a huge variation in sizes - a few Small, a few Medium and a Large and an Extra large. In this scenario, there is a discussion where the Extra large players explains why they think it is extra large and why the Small players explain why they think it is small and so on. In this discussion, some of the hidden scope/ possible methods/ tricks to do it faster come out. At the end of this discussion everyone typically arrives at a common size (scenario 2 or 1 above)
Once you go through this for all the user stories, you have relative sizes which can be converted to story points based on the Fibonacci series. And if you know the team's velocity, you can guesstimate how long it would take. Once the team stabilises after a couple of sprints, these guesstimates are surprisingly accurate.
There are many benefits with this approach:
The whole team is involved the estimation process
The gamification makes an otherwise boring exercise fun
The discussions to normalize sizes brings out complexities and simplification possibilities
If you would like to get your teams to play some Planning Poker, give me a shout :-)