Risk Poker

Planning poker is often used for agile approaches, such as scrum, in order to prepare an estimate relating to the size of the backlog items (for user stories for example). Major differences are often ascertained in respect to story points assigned by different participants.

For example, the software engineer shows a card with five points, the designer shows the eight and the tester the card with 21 on it! If you have ever played poker, you probably recognize this. The cause of this is mostly to blame to the varying insights of the poker players in respect to the required test efforts!

A solution in order to achieve better understanding in respect to these test efforts as well as ascertaining a more unambiguous size estimation of a user story is achievable through playing risk poker (more specifically: ascertaining the story risk) before even starting with planning poker. Nonetheless, risk poker, just like planning poker, requires a ‘whole team’ approach, which means that all team members will gain insight into, as well as achieving better understanding of, all the ‘ins’ and ‘outs’ of the various different testing tasks. During the discussion, which will undoubtedly arise during the risk poker session, an answer will be given – by the team – to the question “How much testing should be done, related to the risks to be covered?” Even in agile environments, or perhaps precisely in agile environments, you do not have all the time you would like to have (due to working in time boxes) to test all of the stories as thoroughly as you wanted to, but you need to make a conscious choice based on the risks to be covered. Much of the discussions appear to provide valuable information on the Confirmation (acceptance criteria) of the user story.

In short, just like with planning poker, also risk poker, besides assigning story points and risk points respectively, gains added value from conversation!