logo

Quick risk strategizing

Google jam board for quick risk strategizing for Dreaming Donkeys Motels cancellation feature

People often ask me about good ways to devise a test strategy for a new epic or feature. Like many practitioners, I find a risk-based approach works well. I’m a big fan of Beren Van Daele’s risk storming with TestSphere cards. I had the good fortune during 2020 to participate in risk storming sessions facilitated by João Proença. (This was before Beren founded Risk Storming Online, and our team had its own internal process). The teams who did risk storming sessions later reported that the sessions helped them think of risks they might not have otherwise, and come up with creative ways to mitigate that risk. It also helps them choose a small number of the most important risks upon which to focus. I learned from João why we humans need to limit our number of choices!

In-person risk storming goes pretty quickly, but I’ve found that doing anything remotely always takes lots more time. Each team risk storming a new feature required two 90-minute sessions to complete the process, for the ones I attended. A good investment, for sure. It’s going to save a huge amount of time in the long run, and prevent potentially serious problems for the company and its customers. Unfortunately, some teams are reluctant to try something new if it involves what they perceive to be a long meeting.

A quick way to strategize

Last year, I was at a new job, and was asked to lead the testing for a significant new feature in our web-based application. We needed an effective test strategy. Being new to the product, I knew I needed lots of collaboration on identifying risks. I was lucky to be on a well-performing team which embraced many good practices, including test-driven development and ensemble (mob) programming. The team had deep domain knowledge, and our product owner collaborated closely with us. We generally had few bugs escape to production, but the impact of any production issue could be huge. I tried to interest the team in trying online risk storming, but they felt it would take too much time and resisted the idea. Maybe I just didn’t do a good enough job of “selling” the idea?  I looked for a smaller experiment to try.

I proposed a 30 minute session with the product owner, dev team members, the designer, and a couple of stakeholders from the business side. I didn’t know if my idea would work, but everyone was willing to give it 30 minutes to see what happened. I set up a Google jam board with color-coded sticky notes.

Google jam board with color coded sticky notes for risks, questions/ambiguities, things to test, risk mitigation ideas, to strategize for testing a new feature

I put the agenda on the right-hand side. To help people think laterally, I noted down some of my favorite questions to ask when discussing a new capability.

I added two tabs to the board – one with the Agile Testing Quadrants, and one with Ellen Gottesdiener and Mary Gorman’s ‘7 Product Dimensions” from their excellent book, Discover to Deliver. I often have these models in front of me when I’m participating in a planning or feature brainstorming session, to help me quickly think outside the box and ask questions nobody else thinks to ask.

For the first 10 minutes of our quick risk strategizing session, I asked everyone to individually add sticky notes for risks, things to test, questions/ambiguities, and ideas for mitigating risks.  None of them had used a Google jam board before and they found it fun and easy. We then grouped similar ones and discussed the various risks and other sticky notes. We identified only five main risk areas, so we didn’t have to dot vote to prioritize the top risk areas. We discussed other ways we might mitigate these risks. After 30 minutes, we were satisfied with the outcomes.

The outcomes formed a great basis for creating a lightweight test strategy to mitigate the risks we identified. This guided our testing as we developed using test-driven and behavior-driven development. We also created exploratory testing charters as stories in the epic to be done when enough feature stories were complete. We also created stories for monitoring and observability dashboard as discussed during the session. It was easy for the team to do these testing and risk mitigation stories when the time was right. This quick process worked well in our context, and we continued to use it to start strategizing testing for new epics.

Let’s look at an example

Here’s an example of what the jam board might look like after a 30 minute session with our fictional team at Dreaming Donkey Equine Motels, Inc. Our app allows customers to book at our member equine motels – it’s like an AirBNB for horses, donkeys and mules. Currently, when a customer needs to cancel a booking, they have to phone us. We want a capability to let them cancel in the app.

Together with the product owner, we wrote up the epic and feature stories. Then we got together with our product owner, marketing person, a couple developers, a tester, the UX designer, and a couple of our motel hosts to talk about potential risks. Here’s the resulting jam board.

Google jam board for quick risk strategizing for Dreaming Donkeys Motels cancellation feature

Collaborating with visuals

In my experience, anytime you get a cross-functional, diverse group of people together, and let everyone write or draw on a virtual white board or sticky notes, you will have a productive conversation and do a better job of thinking outside the box. I like this quick way to organize it – I can usually get people to try something for 30 minutes. Having time for individual brainstorming followed by group discussion promotes creativity and lateral thinking. If you end up with more than six risks, it’s easy to dot vote to choose the top six to focus on.

Perhaps a team will see the value in this, and decide to go to a more in-depth process such as risk storming. It’s a small experiment that you can try so that you can build a test strategy that mitigates the biggest risks.

If you can think of a catchier name for this, let me know!

4 comments on “Quick risk strategizing

  1. Thanks – This sounds like an interesting process, I wonder if this risk storming process could benefit from some list of common risks (some generic like the SW quality characteristics, and some more internal product specific) which can also be discussed after the team raises their ideas, to provoke more thought on things the team might have missed.
    I usually found using a cross-feature table with column headers describing areas feature can effect, types of tests etc and sub items of these areas quite thought provoking when we review test cases design, I create such a table and add to it from other stake holders ideas and new items as they come along in following versions – I normally use that by myself first, marking in traffic light colors which items I consider risky (high need to test) and which are redundant, then during the review meeting we quickly go through these (mainly issues I am not sure about), and just by going through them it helps others to think of similar issues and raise more related ideas.
    I think creating such a table would benefit the risk storming, helping to invoke more ideas into the discussion.
    Kobi

  2. I love this idea! Have you published any articles or blog posts or done talks on this? I’d love to see some examples.

    And to be clear, I don’t want this to be confused with risk storming, which Beren came up with, using his TestSphere cards. The goals are similar, but risk storming is a more structured and detailed process. I have seen such great results from risk storming.

    There are many great approaches, for lots of different situations! Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

Categories
Archives

Recent Posts: