RiskStorming In Agile Teams With TestSphere

By Gem Hill

As a software tester, I am always on the lookout for new ways to get teams talking and sharing knowledge and information. Though Agile ceremonies like retrospectives and standups are good for this, they often focus on the short term, immediate work, as opposed to long term goals for the team, such as understanding risks around developing and delivering a software product.

Being in research and development means I may start working with an already established team. This means there may a lot of tribal or implicit knowledge which we need to make explicit, especially if the team is well established.

One bit of information that I wanted to find a new way of getting teams to talk about was long term or overall risks. So I set about looking into risk identification solutions and organising a risk discovery session for my teams.

Looking At Risk Identification Solutions

I researched several ways the teams could look at risk, for example,  A Practical Guide to Testing in DevOps by Katrina Clokie has some good options for looking at different areas of the development pipeline.

Additionally, there’s the headline game, where you ask stakeholders to tell you what their worst case newspaper headline would be and then work to mitigate that risk, which I’ve used before in agency to make sure we know what’s most important for the client we’re working with. You can expand the game to talk about what would be a nightmare bad review on Tripadvisor or Yelp, and try to make sure you’ve covered that as well.

What I really wanted was a more holistic way to look at risk that covered both the developers and the stakeholders’ idea of risks around the application, and immediately thought of RiskStorming with TestSphere cards as a way to do this. This risk discovery session would be the first dedicated session on risk I’d done, so as RiskStorming comes with good structure and instructions and is relatively simple meant I wasn’t focusing too much on facilitating and instead on helping talk about the cards and risks.

Once I got my TestSphere cards, I knew I wanted to try a RiskStorming session as a way of identifying risks with my team. I loved my TestSphere cards for giving me new test ideas anyway, but the idea of using them to talk about risk really intrigued me.

Introduction To TestSphere

Before I jump into RiskStorming, I want to introduce TestSphere. Testsphere is a card game for testers! It was developed by Beren Van Daele and is sold through Ministry of Testing.

The game centres around storytelling. There are 5 types of card in each pack. Players take a card (or two, or three), and start to share stories about the cards picked. The story that covers all the cards ‘wins’ and then more cards are picked. In all honesty, the game is often lost to storytelling and sharing knowledge about testing, which is absolutely the strength of TestSphere!

There are many ways to use TestSphere:

  • You can draw a card at random if you feel your thinking needs a change or a refresh,
  • You can look at the methods or heuristics listed to find ones you didn’t know before and do some guided learning.
  • You can also run RiskStorming sessions!

Discovering RiskStorming

RiskStorming is a way to expose the biggest and most important risks to a product or project. It’s a way to discuss and discover things that are often quite scary to talk about. No one really wants to dwell on ways their product could catastrophically fail. The cards provide a nice, fun, colourful vehicle to discuss these.

Introducing RiskStorming To Teams

Since I started working at the BBC, I’ve run two RiskStorming sessions, with two different teams. In both teams, I am the only tester. The first session was with the primary group I work with; they are used to having a tester, and the product was a fairly mature one. The second session was with a new team: the team never had a tester before and the project was moving from a prototype phase into a more mature project, which was why they wanted me on board, even if it was only part time.

Onboarding New Members With RiskStorming

When you’re new to a team you might not know which questions you need to ask, or the areas you need to focus on to perform your job. A RiskStorming session can be a fun way to get team members up to speed on the risks and important quality areas of the project without trying to cast around for questions to ask and documentation to share.

Given the context, my knowledge of the teams, and the fact that I’d only played RiskStorming once before during Testbash Manchester, I decided to modify the RiskStorming game slightly.

The original RiskStorming game involves looking at your risks, then using the test techniques cards to put together a test plan for mitigating these risks.

As one of the teams I was working with were working with entirely new technology to me and weren't going to have a full time tester on the team, I was more interested in seeing how the developers wanted to mitigate these risks in their process without introducing new testing terminology and with me only adding in my testing knowledge where appropriate.

How To Win Friends And Run A RiskStorming Session

Things you will need for a RiskStorming session:

Setting Up A Session

First, I took out all the Quality Aspect cards. There are twenty in each pack, they’re blue in colour and cover aspects such as Accessibility, Stability, Localisation and Data. We had about fifteen minutes for this exercise. The team familiarised themselves with each card and then started narrowing down the list to the top Quality Aspects for our project. I limited the top risks to six, though in one team we only found four which really affected our short term work (I plan to do a second one for the longer term work once this project is done).


Data Quality Aspects card from TestSphere deck

If the discussions had raised a quality aspect that wasn’t in the pack, my plan was to allow a new quality aspect to be added using a sticky note. This didn’t happen but I laid this option out at the start so people knew they weren’t limited to just the cards.

Getting The General Concept

Talking about quality aspects was the first step towards opening up the team’s idea of risk and quality to more general areas rather than focusing on specifics in the beginning.  The team might not have thought about things like Accessibility or Testability as an area they wanted to focus on, and so introducing new ideas and opinions was a good way to get the team chatting and sharing knowledge.

Some cards were easy to dismiss. For example, localisation was not something we needed to think about for one of our projects, as it was a short term project for the UK only. There were other cards, like adaptability which prompted a lot of discussion but was ultimately not included in our top risk areas.

Once the team narrowed down the cards, they placed them in the middle of the table and picked up some post-it notes.

Writing Out The Risks

The team spent about fifteen minutes writing down specific risks to each aspect for the project. They didn’t chat much during this part, the team was focused on writing down risks. Once the team were finished writing, they collated the risks. The overlapping ideas were grouped and duplicates were merged. The team then talked about each one, making action points where needed. I shared how I would test things as the team worked through the risks.  I also shared what they could do to help me with testing.

The team left the session with a raft of action points, some things for them to research, and a plan.

Two RiskStorming Sessions

Being in research and development meant I was working with very different teams in different parts of the process.

One team I did a RiskStorming session with has a product in production, visible to the public. They had a tester and knew what to expect.

The second team had never had a tester before, and I only helped part time. The team were open to my input, but something like this was entirely new to them.

Both teams really enjoyed the session. The cards are colourful, the examples are useful, and they don’t need a huge amount of explaining.

Run a RiskStorming Session

I highly recommend running a RiskStorming session with your team. Ministry of Testing has created a video on how to run RiskStorming session and you can download different sizes of the RiskStorming board below.

I think RiskStorming is a good way to spend an hour, even if your team has been formed for a while. You could learn more information about quality aspects. You can formulate some testing plans, and see what could be needed. Needs could range from building up some skills or researching subject matter. The loosely structured conversation with your team can reveal important information and many assumptions.

If you are a new team or new to the team, then there are even more upsides to doing a RiskStorming session. It gives you the chance to see how the team deals with talking about things that might be scary, and the possibility of failure. It’s not an easy thing to think and talk about in most circumstances. This is a low stress way to face those fears and see how you can deal with them as a team.

As your team shares information, “silos” and “invisible walls”  become easier to navigate. People might have knowledge they didn’t realized they had previously. Sharing skills and knowledge can help the team understand who knows a topic well and encourage collaboration between team members.

What has been especially useful about these sessions for me is that in each one there has been a risk that was only in one team member’s head. It wasn’t until the RiskStorming session that it was shared with the team as a whole and we started to tackle it together.

The best way to deal with risk is to expect it and plan for both avoiding and dealing with it. RiskStorming is a great way to start this process. It’s flexible enough that you can use it in ways that fit best for your context and teams. One example you might try is taking photos of the cards and put them online for a remote RiskStorming session! TestSphere and RiskStorming are great tools to add to your tester’s toolset.


Author Bio

Gem works at the BBC and has recently joined the Voice and Conversational Interfaces team, working on BBC skills for Alexa and other voice platforms. She has two podcasts (Let’s Talk About Tests, Baby, and Inner Pod), and can be found on twitter @Gem_hill