Agile Risk Management

The Scrum guide doesn’t say anything about how the Scrum Master or Product Owner should be managing risks, except that risks should be measured considering the state of the artifacts. As a framework, Scrum gives you the backbone and the minimal activities that needs to be performed in order to obtain value from the framework. However, in the real world projects goes beyond activities like backlog grooming, daily standups and retrospectives.

Now, before you think Scrum projects has nothing to do with risks, please think twice. Every single project or activity has risks. Big or small, they are part of the day to day work of the team. What happens if we loose the server? The main architect leaves the company? Or what we can do if the infrastructure is not in place for development by the time we should be releasing the product? All these questions are potential risks that can affect the team, the project and the product.

In my view, risks should be worked in 2 ways: by the product owner for product risks and the Scrum Master for the development risks.

The product owner should identify, prioritize and mitigate risks that are related to the product itself. What if we cannot launch by this date? What happens if the product does not have the acceptance we are planning for?

The Scrum Master should manage risks that are related to the development of the product, and to safeguard the team in case they happen. From Scrum point of view, it is the duty of the Scrum Master to be a servant leader, thus supporting the team during the sprint and removing impediments so the team can freely move on with their tasks. Since it is the Scrum Master duty to do all this, it is his/her interest to identify, analyze and mitigate risks so impediments are removed even before they existed.

However, not many Scrum Masters do that. Why? The main reason I find is that first it is not described in the framework, so they feel that it doesn’t need to be done. Second, simply because most doesn’t know how to do it, or even question why they should do it. You should do it to anticipate and mitigate issues to happen to the project and to the team before it becomes a reality. This is also “removing impediments”.

How should you do it? First, Identify risks questioning “what if” scenarios to the team,. Have the team in a room to identify and discuss risks and impacts. Log them and prioritize them. Create stories for these risks and tasks to mitigate the risk to happen. Treat risk stories the same as you treat technical stories. Have the team to analyze them, estimate them and add them to the backlog as a continuous improvement.

Doing this exercise will help you, as the Scrum Master, to remove future impediments and issues that could hurt the success of the project and the product.