Software development is inherently risky. From the moment we pick up a task to the day it goes live in production, we're dealing with uncertainties that can compromise quality. The key isn't to eliminate risk altogether (that's impossible), but to identify, understand, and manage it effectively instead.
Risk is always present
A small feature addition might seem straightforward but can still introduce performance bottlenecks, break existing functionality, or fall short of user expectations. And with a bigger change—like a refactor—those risks only grow.
The most dangerous risks are often the ones we don’t see coming. That's why it's important to identify them before they become actual problems. If we're aware of the risks ahead of time, we can take steps to reduce or prevent them.
Identifying risks
There are various ways to identify risks, depending on the complexity of a change and how much uncertainty it involves.
One technique that works well is Brisk De-Risk, introduced by Lisa Crispin. It's a short 30-minute session with team members and stakeholders, where everyone brings their own perspective to identify possible risks related to a specific user story.
You can run the session with an online jam board (for remote meetings) or physical colored sticky notes (for in-person ones). To keep things organized, use different colors to represent:
- Risks
- Outstanding questions and ambiguities
- Things to test
- Risk mitigation ideas
Here's how a session typically goes:
- Each participant adds their notes individually (10 minutes)
- Group similar notes together (5 minutes)
- If a lot of risks have been identified, use voting to decide which ones to focus on (5 minutes)
- Add or refine test ideas and mitigation suggestions, as needed (10 minutes)
In the end, you'll have a list of identified risks, things to test, and ideas for how to handle the issues. Be sure to also clear up any questions and ambiguities, as those can be risks in their own right.
TIP: A list of questions can help get the conversation going, helping team members think outside the box and spark discussions to uncover more risks.
Another useful technique is the Pre-Mortem. In this exercise, the team imagines that a change has gone terribly wrong in the near future and then works backwards to figure out what might have caused it.
- Participants write down possible reasons for failure on sticky notes.
- The notes are grouped into themes.
- The group discusses and prioritizes those themes.
- Finally, you define mitigation steps together.
Just like the Brisk De-Risk, the goal of this session is to create a clear list of potential risks and ways to deal with them. Both methods are easy to introduce and can be especially helpful for teams not yet fully familiar with risk management. And with a bit of practice, these sessions can become more efficient and effective over time.
Classifying risks
When dealing with risks, there are two factors to consider:
- Impact: How much damage would it cause if this risk happened?
- Probability: How likely is it that this risk will occur?
A good way to visualize this is with a risk matrix, typically a 3x3 grid plotting impact against probability.
TIP: If more nuance or granularity is required, you can expand the matrix with more levels of impact and/or probability to get a more detailed view.
To classify the risks together as a team, try using Risk Poker, a technique similar to “Planning Poker”.
Here's how it works:
- Go through each risk with a diverse group of team members and stakeholders.
- First, everyone gives a score (1–3) for probability.
- After a quick discussion, the team agrees on a final score.
- Repeat the same steps for impact.
- Multiply the two numbers to calculate the overall risk score.
These discussions are often very valuable, as they ensure a shared understanding of the risks at play. Team members learn from the different perspectives and can apply that knowledge in future risk classification sessions.
The result of the Risk Poker session is a prioritized list of risks, giving you a clear picture of which ones need to be addressed right away and which ones are less critical. A high-impact, high-probability risk will require immediate attention, while a low-impact, low-probability one may be perfectly acceptable.
Next steps
These example techniques work best when they become part of your regular workflow, rather than one-off activities. Try incorporating one into your next sprint planning or user story refinement session.
Remember: risk management isn't about making perfect predictions or eliminating every single risk. It's about making conscious decisions—knowing which risks you're willing to take, which ones to avoid, and which ones to actively manage; all to better prepare for uncertainties that will inevitably arise.
Start small, experiment, and build from there.