Risk Poker

Purpose

Risk Poker applies the same simultaneous-reveal mechanic as card-based estimation to risk assessment. By having team members independently rate risks before discussion, it prevents groupthink and surfaces hidden concerns.

At a glance

How to run

1. List risks (10 min) — Brainstorm or review a pre-existing risk register. Select the top 10–15 risks to assess.
2. Explain the scale (3 min) — Use cards numbered 1–5 for likelihood and 1–5 for impact (or use Fibonacci).
3. Assess likelihood (10 min) — For each risk, everyone selects a likelihood card privately, then reveals simultaneously. Discuss outliers briefly. Record the consensus score.
4. Assess impact (10 min) — Repeat the simultaneous-reveal process for impact.
5. Calculate risk score (5 min) — Multiply likelihood × impact. Plot on a risk matrix.
6. Agree on response (7 min) — For the top 5 risks: Mitigate, Accept, Transfer, or Avoid. Assign owners.

Materials needed

• Risk Poker cards (1–5) per person, or a digital polling tool
• Risk register or brainstormed risk list
• Risk matrix template (likelihood × impact grid)
• Shared document for recording scores and actions

Pitfalls & common mistakes

• Only optimists in the room — Include diverse perspectives (QA, ops, security) to surface blind spots.
• Anchoring on the first speaker — Enforce simultaneous reveal; do not let anyone call out a number first.
• Assessing too many risks — Cap at 15 per session; prioritise the most uncertain ones.
• No action after assessment — Every high-risk item needs an owner and a mitigation plan.

Inclusion & accessibility

• Use numbered cards with large print.
• Allow written explanations for outlier positions in addition to verbal ones.
• Ensure remote participants use a tool that hides votes until reveal.

Variations

• ROAM — After scoring, classify risks as Resolved, Owned, Accepted, or Mitigated.
• Risk burndown — Track risk scores across Sprints to show mitigation progress.
• Threat modelling poker — Apply the technique specifically to security threats.

When NOT to use this

• If the team has no identified risks — run a risk brainstorming session first.
• If the project is nearly complete and risks are already realized — run a lessons-learned session instead.

Source & further reading

• DeMarco, T. & Lister, T. (2003). *Waltzing with Bears*. Dorset House.
• Hillson, D. (2009). *Managing Risk in Projects*. Gower.