User Stories and the Backlog: Planning Poker

The two most common ways of generating team-based story-point estimates for backlog items are affinity estimating and Planning Poker. Affinity estimating permits very rapid estimation of large volumes of backlog items. Although it benefits from having previously-estimated stories available as reference points, the process is less sensitive to their absence. It works brilliantly well at the inception of a new team or backlog, as well as during release planning. 

Planning poker works better when the team only needs to estimate a few stories, such as during Backlog Refinement and Sprint Planning. It’s almost a prerequisite to have an established backlog with enough previously-estimated stories to act as relative reference points, but teams can work around this if they have to. Planning Poker can also generate more robust discussion, especially when the game’s rules are strictly followed and multiple rounds are played when estimates diverge. 

So, here’s how to play planning poker. First, obtain a set of planning poker cards for each participant. While electronic versions of planning poker cards exist, I suggest using inexpensive, widely-available, printed cards instead. Allowing the use of electronics can create significant distraction and really slow down your backlog refinement and sprint planning events. You can also show your fist and then raise some fingers… with a twist. Showing one finger is a “1,” two fingers is a “2,” and three fingers is a “3,” just as you’d expect. However, four fingers is a “5,” five fingers is an “8,” six fingers is a “13,” and so on. So your number of fingers isn’t the number of points, but rather the index of the Fibonacci sequence.

Second, present the backlog item, either as a paper-based card or sticky note or on a large display if you are using Agile software. Have a conversation about the as a team, asking questions and updating the card with new confirmation items as the team discusses. Once you have discussed the story in depth, call for a vote.

For newly formed teams, or teams with new members, it can be particularly helpful to briefly review previously-estimated stories for reference. Once you call the vote, each developer should secretly choose a single planning poker card from their hand that reflects this backlog item’s relative complexity, uncertainty, and effort compared to other user stories. They should vote even if they do not have subject matter expertise and even if they are not sure they will contribute to the completion of the item that sprint. No person, including the product owner or scrum master, may attempt to influence other’s votes at this time. The product owner may not vote. The Scrum Master may only vote if they are also a member of the development team and will also act as an individual contributor during the sprint. Many teams like having developers hold up the card (or smartphone) with the back facing the rest of the team, so that it is clear who is ready to vote and who is still deciding on a number.

Once everyone has a number, the team should reveal their votes simultaneously. If every team member happens to choose the same number, this number becomes the estimate and the team can move on to the next story. This only rarely happens, however. So facilitate a discussion around why people voted as they did. You can start with the lowest and highest votes. The tone should be one of curiosity: why did the developer vote the way they did? After all perspectives have been heard, secretly vote again. If the numbers fully converge, note the estimate and move on. If not, the team has a judgement call to make. The formal rules of the Planning Poker game dictate that the team should continue rounds of discussion and secret voting until all estimates converge. Most teams will not tolerate this structure. Further discussion usually leads to greater shared understanding and estimate convergence. However, if most of the team has converged on one estimate and there are one or two holdouts for an adjacent estimate—for instance, most of the team thinks the item is an 8 but one person thinks its a 13 and one thinks its a 5—it’s not unreasonable to simply call the item an 8. If you’ve got a few 1s and a few 13s in your mix, though, you probably have more talking to do.