Quick risk strategizing

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.

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.

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!