risk-storming-facilitator

Overview

Risk-storming is a collaborative exercise where the team brainstorms what could go wrong with a feature or release. The output feeds directly into the risk matrix (per risk-matrix).

The format originates from threat modeling exercises (notably Adam Shostack's Threat Modeling: Designing for Security) and Gojko Adzic's risk-driven testing community, adapted as a general QA technique.

When to use

• A new feature is about to enter development; the team needs to identify risks proactively.
• A release scope is set; pre-implementation risk review.
• Quarterly: the team revisits its risk register.
• Post-incident: a root cause investigation surfaces new risk categories worth brainstorming.

Step 1 - Pre-session setup

Schedule 60-90 min. Invite:

• 2-4 engineers (product code knowledge)
• 1 QA / SDET
• 1 PM (business context)
• Optional: SRE / Security / Compliance (if relevant)

Pre-distribute:

• The feature spec / story
• The acceptance criteria
• The current risk matrix (for the area, if exists)
• Recent incident postmortems for similar features

Step 2 - Session structure

00:00-00:05  Kickoff: facilitator presents the feature scope; reads ACs aloud
00:05-00:25  Silent brainstorm: each participant lists 5-10 risks (post-its or shared doc)
00:25-00:40  Affinity grouping: cluster risks by category
00:40-00:55  Score each risk: impact (1-5) × likelihood (1-5)
00:55-01:15  Mitigation discussion + owner assignment
01:15-01:30  Review + close: confirm action items

The silent-brainstorm phase is critical - without it, the loudest voice dominates and group-think hides real risks.

Step 3 - Prompts per category

The facilitator brings prompts to drive the brainstorm:

Business risks

• "What if the calculation is off by a cent?"
• "What if a customer applies the same code twice?"
• "What if the discount stacks differently than expected?"
• "What's the worst incorrect outcome the customer would see?"

Technical risks

• "What if the third-party API is down?"
• "What if the DB migration runs partially?"
• "What if two users hit this concurrently?"
• "What's the longest-running query under this feature?"

Regulatory / compliance risks

• "What if this stores PII?"
• "What if the user is in EU / California?"
• "Are there regional pricing requirements?"

UX risks

• "What if the user's network is 3G?"
• "What if the user is using a screen reader?"
• "What's the first-time user experience?"

Security risks

• "What if an attacker controls the input?"
• "What if a logged-in user accesses another user's data?"
• "Where's the auth boundary?"

Performance risks

• "What's the cold-start time?"
• "What's the per-request latency budget?"
• "What's the concurrent-user ceiling?"

The prompts are starters; the participants extend per the feature.

Step 4 - Affinity grouping

After the silent brainstorm, cluster:

Cluster: "Payment failures"
- Stripe webhook delivery failure
- Stripe API rate limit
- Customer card declined mid-checkout
- Customer cancels mid-checkout (browser back button)

Cluster: "Promo math"
- Off-by-cent rounding
- Stack two promos
- Apply expired promo
- Apply promo to free-shipping order

Cluster: "EU compliance"
- VAT calculation
- GDPR data export
- Cookie consent

Cluster: "..."

Clusters reveal that some risks are different facets of one underlying issue (e.g., "payment failures" is one architectural concern; mitigations may apply across the cluster).

Step 5 - Score

Per cluster (or per-row if the cluster has heterogeneous risks):

The team agrees on each score via brief discussion (5 min cap per risk). When discussion exceeds the cap, the facilitator notes the disagreement and moves on; revisit after the session.

Step 6 - Mitigations + owners

For each Critical (>=15) and High (9-14) risk:

Lower-priority risks (Medium / Low) get logged but may not get immediate mitigations.

Step 7 - Output to the risk matrix

The session output flows directly into the matrix per risk-matrix. The matrix file becomes the canonical record; the session notes (silent brainstorm results, discussion points) get attached as appendix.

Step 8 - Post-session

Within 1 day:

• Author / update the risk matrix file.
• Create tracker tickets for each action item.
• Schedule a 15-min check-in 1 sprint later to verify mitigations shipped.

A risk-storming session without follow-up is wasted.

Anti-patterns

Limitations

• Time investment. 60-90 min × ~5 people = 5-7.5 person-hours per session. Don't run weekly.
• Facilitator skill matters. A weak facilitator produces a weak session.
• Group-think risk. Even with silent brainstorm, group dynamics can suppress disagreement. Encourage explicit "I disagree" framing.
• Doesn't predict unknown unknowns. Risk storming addresses identified risk classes; new ones emerge from incidents.

References

• Adzic, G. on risk-driven testing - community references at gojko.net.
• Shostack, A., Threat Modeling: Designing for Security (2014) - foundational for the structured prompt approach.
• risk-matrix - the artifact this session produces.
• risk-based-test-selector, risk-based-test-planner - agents that consume the matrix to drive test scope decisions.