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. The cause thereto is mostly to blame to the varying insights of the poker players in respect to the test efforts required thereto! 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. In short, just like with planning poker, also risk poker, besides assigning story points and risk points respectively, gains added value from conversation!
For this Wiki we have used the Ron Jeffries 3 C’s approach (Card, Conversation, Confirmation) in order to create a story card. An actual (physical) Card (often a post-it note) with a user story on it. The Conversation segment provides additional explanations relating to the user story. This could be a visual annotation (figure) on the Card, or a reference to, for example, a use case and email exchange. The Confirmation (also called Acceptance) segment, usually on the back-side of the Card, contains those elements needed to demonstrate the acceptance of the user story.
‘Quality is key’, is the credo in scrum. But based on the story risk – which is ascertained prior to the sprint – it is possible for stories with a higher risk to be tested more extensively than those stories with a lower risk. The risks and the ways in how to cover these are directly related to the acceptance criteria, as indicated on the Confirmation segment of the story card. Here we can often find good situations as well as error situations and sometimes even a hint as to which test approach and coverage types should be used. In fact, a Confirmation completed in this way is a synonym for the Definition of Done for this specific user story. Furthermore, when thinking of ways to cover story risks do not just consider testing, but also, for example, verifying stories as per being Independent, Negotiable, Valuable, Estimable, Small and Testable (INVEST). And also think about approaches such as Acceptance Test Driven Development (ATDD), Behavior Driven Development (BDD) and Test-Driven Development (TDD).
Risk poker is a fun and highly effective manner which can be used to assign risk points to user stories. There is no set rule as per which to execute risk poker, but since most scrum teams work with poker cards anyway it is easy to take the next step and use these same cards for risk poker as well. Below we explain the approach when using cards 1, 2 and 3 (image left). But other sets are most certainly also possible. Instead of cards it is also possible to use a mobile app. (image right)
Definition of story risk
A story risk is the chance (odds) of a story failing relative to the expected damages (in production) if that would indeed occur as such:
|Story Risk (risk points) = Chance of Failure * Damage
On the internet we can find many different variants of risk poker approaches described as such, but the basics are all very similar. And usually all are based on the ‘standard’ product risk analysis approaches.
When to play risk poker?
Executing risk poker can be done at the same times as when executing planning poker. Usually during the release planning at global level and during the sprint planning at detailed level. During the sprint planning at detailed level; because at that moment the user stories (including the Conversation segment of the story card) should be ‘sprint ready’ after an eventual ‘refinement’. Risk poker could eventually be executed during or at the end of the ‘refinement’ session.
Just like with planning poker, risk poker is a ‘whole team’ approach. However, there is a difference. The scrum master facilitates the risk poker session and will himself/herself not participate with the poker game, but the product owner, in contrast to planning poker, will participate. After all, the product owner represents all the stakeholders and will be able to provide valuable input, especially in the aspect of damage.
- Each team member gets/selects cards 1, 2 and 3.
- The scrum master reads to user story at the base of the upcoming poker game.
- The scrum master requests the chance of failure estimates.
- Each team member ascertains for himself/herself which card he/she believes represents the correct chance of failure estimate and puts this card face down on the table.
- Once everyone has made a selection then the scrum master will ask everyone to reveal their cards simultaneously.
- If everyone has selected the same number of chance of failure points then the chance of failure estimate for this user story can be considered complete.
- If the chance of failure points differ then these differences will be discussed by the team (with focus on the deviating values).
- Repeat steps 4 to 7 until consensus has been achieved, after which the scrum master will write down the chance of failure points.
- Repeat steps 3 to 8 in order to get a damage estimate.
- The result (the risk points), the chance of failure * damage, will be written down on the story card by the scrum master.
After having estimated the risk points for all the user stories the team will execute the last verification. Do the user stories with the same number of risk points – intuitively - indeed represent the same risk? Depending on the response thereto it is possible to adjust the points of a user story. With risk poker is not the idea to get a perfectly accurate estimate. The main thing is to make sure that the entire team deliberates thereto in order to achieve mutual consensus.
It's a good idea to work with time boxes. For example maximum 5 minutes to play damage poker and 5 minute to play chance of failure poker. If by then no consensus has been achieved then there are various possibilities to obtain an end result. For example; selecting the highest values for chance of failure as well as damage in order to be on the ‘safe side’ or at the end of the day playing poker once again for those stories (as per the time box principle) for which no consensus was achieved earlier. It does not matter which method is selected to obtain the end result as long as the method to be used is indicated as such before the game of poker is started!
Visualization during the poker game
Visualizing an individual story risk in relation to the other user stories can be achieved by sticking (with glue or tape) the user stories (which are on post-it’s), while playing poker, on a big sheet of paper using a classification as indicated below.. An additional advantage thereto is that after playing poker it is possible to remove the stacks from one slot/box while asking the question; ‘do these user stories indeed represent the same risk?”. After which it is possible to switch/change the slot/box of some of these user stories.
User Story risk visualization
Now that all the team members are familiar with the story risk and thus also understand that a story with a higher risk needs to undergo more severe testing than a story with a lower risk we see that the follow-up step – planning poker – will result in less discussions and deliberations about the test efforts. This in turn means that consensus in respect to the estimations relating the story points will be achieved faster. Furthermore, all team members often, while playing risk poker, mention specific test focus points which are recorded on the Confirmation segment of the story card.
Reports during the sprint
During the sprint it is possible to visualize the progress of the coverage of the story risks through the use of a burn-down chart of the covered story risks.
Burn-down Chart story risks
Product Risk Analysis - Execution
- Executing the product risk analysis (PRA)
- Alternative PRA
- Risk poker
- BDTM Product Risk Analysis
- Dealing with incomplete information
- Product risk management