In the past few weeks I worked out an Agile risk analysis with my collegue Julien Schouten. By this way I would like to share are idea’s on this analysis.

Most of the software developed this time, is developed in an agile way (Agile Scrum). In the old days we had a waterfall process where we did some risk analysis and modeling before we started the development process. Most of the risk analysis done where written very extensive. The funny thing here is that most of the managers and customers that required the risk analysis never read a word of it.

Now, in the modern days, we develop software in an Agile way. We use scrum as a development process, only do some documentation of necessary, and do nothing like an explicit risk analysis.  Implicit we do a risk analysis. In the scrum process you assign story points to the user story. A story point is made of three components:

  • Uncertainty
  • Complexity
  • Effort

When a user story is ready for the development team to pick up, we can say that the uncertainty has gone, and the story point is only based on complexity and effort. We could also say that when a user story is very complex and requires a lot of effort, the chance on bugs and failures will increase. That is a risk, isn’t it? It’s a risk that a user story will not work in the way that the customer expects it to work.

Risk Analysis in Agile Scrum

When you want to do an explicit risk analysis in the scrum process, you should let team members estimate on the complexity of the user story and the effort that is required to complete the user story. These estimations should be done in the backlog refinement session, when the uncertainty of a user story is almost 0%. These estimations can be done with values of the Fibonacci series. The values of those estimations can be used to create a quadrant.

Risk Analysis Quadrant

You can split up the quadrant in four fields. User stories that will end up in field “A” will have a low risk, user stories that end up in “C” or “D” will have a medium risk. User stories that end up in field “D” have a high risk. These are the ones that require a lot of effort and are very complex to build.

Managing risks in an agile way

Now you know in which field of the quadrant a user story will end, you could add extra tasks for that user story to manage that risk. For example:

  • Field “A”
    • Quick regression testing
  • Field “B”
    • Quick regression testing
    • Code Review
    • Pair programming
  • Field “C”
    • Extended regression testing
  • Field “D”
    • Extended regression testing
    • Code Review
    • Pair Programming
    • Split the user story


When you estimate the complexity of a user story and the effort that is needed to complete the user story, you are able to create a risk quadrant. This risk quadrant will show you the risk of a user story and helps you to manage that risk. This way of risk analysis doesn’t take a lot of time and will improve the quality of software you deliver to your customers. You could even share the risk quadrant with your customer/product owner so that they know where to focus in the acceptance testing phase.

Share This