Take the Gambling out of Planning Poker

Teach students to use planning poker for discussion

We all know estimates are guesswork. I often introduce this topic with a simple question: ‘how long will it take you to go to the library from here to get a cup of coffee?’ In an ideal world, on our campus, this might be between 15 and 30 minutes depending up which building we’re in for this session. Student guesses are often close enough, and reasonably argued. A few realise there is no correct answer.

I say the only way to find out is to actually do it, as any number of things could happen on the way. It is a gamble of sorts. At one extreme, all goes well, and they bring back a coffee in the estimated time. Hurrah!

Alternatively, things go wrong. A seagull attacks the person as they eat the cupcake they bought too, and drop the coffee. As a result they go back for another coffee and take longer. Or, they meet a friend on the way, and chat for a bit, which adds time to the errand. Or, the person get there and fins it is closed, so they have to go to a cafe on the High Street, which takes more time. Or, in the happy version, they check their lottery numbers on the way, and realise they won big, so drop everything and go claim their prize. Or, in the unhappy version, they are hit by the number 20 bus, and end up in hospital, so the coffee takes a week. There are many variations.

There is no correct answer

In other words, there is no way to know how long it might take, as there are many variables. This is not to say, you can’t do things to minimise the risks, but rather that until it is done, you don’t know the correct answer. These same issues arise at the start of their student projects, which often makes them nervous about starting. They are unsure of where to start, and how long it might take to do something.

I use a session with planning poker cards to illustrate the issues around these problems. If you’re not familiar with them, then the quick answer is that they’re Fibonacci numbers printed on cards. Each card has one number, usually from 1 to 100 or maybe more. Some decks also have a coffee symbol, a question mark, or an infinity symbol to say ‘time for coffee’, or ‘I have no idea’.

I find these card decks on exhibitor stands at agile conferences. Look for them next time. In the meantime, you can also print out this version for your students to use.

Using the planning poker deck

Pick a general scenario with stories for the student teams to discuss. I use a pizza example, as most students can relate to ordering a pizza online. This has a slide showing stories, which you can see below. Tell them the scenario is a friend wanting to see if it’s worthwhile starting a bigger business, so they only want a very, very, basic site to start with as in release one. If it turns over enough business, makes enough money, then they move onto the other stories.

Each student gets one colour of the deck and the team estimates the complexity of an agreed upon story. Each person picks the card they think represents the complexity, with higher numbers meaning more complexity. Low numbers suggest it’s easier, and high numbers mean harder. When everyone has a card, then they share them. If someone has a higher/lower card than the others, they should explain why they think this is the case. When everyone is in agreement on the number, then they move to the next story.

The number for the estimate has nothing to do with the amount of time it might take to complete. The number only signifies complexity. In any case, estimating with time only leads to unhappiness, as any number is a gamble. We want to take the gambling out of planning poker. Planning poker is for discussion.

The discussion is the key part of planning poker

The planning poker discussion between the team members about why it is more/less complex enables the team to bring everyone’s experience to bear on the story. This is when the person, who knows a bit more than others about databases, or deployment can explain why something is more/less complex than others realise.

As with the going to the library question at the start, the goal is to illustrate the variability of issues, which might impact on a user story. This is the part that comes out when people consider each story on their own before revealing their choice. This exercise also gets them talking to each other too, so aids team building as well.

The advanced version looks at slicing stories smaller

If there is time, have the students do a few rounds where they aim to have all stories be below 10. If they are larger, then the team discuss how they might split the story into smaller slices that are each less than 10. For example, in the above scenario, you might do this without a database.

Slicing stories smaller forces students to bring their assumptions into the open for discussion. The students consider simpler options. This, in turn enables bigger assumptions about the business idea in general be validated before spending too much time and effort.

By slicing stories smaller, we can do away with the gambling of planning poker. We want to discuss the issues around stories, and slice them smaller. Smaller stories are easier to work with too, so everyone wins.

Sign up for the mail list below for a free copy of the collaboration rules as a PDF from the book.

---