User Story Risk Quadrants

On my way back from Agile Testing Days 2013 I had an conversation with Gitte Ottosen of course it was about testing. We talked a bout risk and how to address that in agile. Therefore I have a very simple but effect method to get the team more involved.

I call it User Story Risk Quadrants it is designed to let the team discus how much risk is involved with the user story.

In the past I gave presentation on risk in agile so I search for an old presentation and found out that I did not have anything online to point out to. I send her an email with an example. Her response to my email  was “I just wanted to let you know that people are really loving the risk quadrant you showed me.”

This is why I wrote this blog.

 

What is it?

It is a detailed version of a standard Product Risk Analysis or a graph to show the combination of likelihood and impact.

This can be used in a project if they want to use a risk based approach. The idea is focus on the more riskier part of the software. You can find these graphs for example in a master testplan. As in Agile there is no focus on the master testplan so I moved the addressing risk to a lower level, the user stories part. 

Why should I use it? 

I see two problems and if you like to solve them

1. The high and low risk areas are tested the same way.
2. There is no conversation about risk in the sprint

1. Isn’t it strange that risky areas are tested the same way?

There is a golden rule I use. Diversify in technique and in data. The problem sometime is that you as an tester should at least know 15 techniques to diversify. If you know one you need to learn more first.
The use of User Story Risk Quadrants is a good way to show the rest of the team that this user story will be tested more in dept and the other only by a simple error guessing. It is hard for some team member to diverse the test. Therefor this helps them to remind to diversify. Example PPT  Example key

2. As an tester you are the test mind in the team. When the risk is high the level of testing is chaining accordingly and you can have a discussion why this user story is needs more testing.

How to use it?

I start by asking the Product owner and the development team about the impact and likelihood of that user story. Add the result to the user story.  As a big fan of visualization I like put it on the wall

When to use it?

Most likely I use it during the preparation of the user story with the Product Owner. User stories are not done when they do not have a risk attribute.

And during the planning I tell the team that this user story is a quadrant 4 user story and that means these kind of tests.