In my opinion, Risk Management is one of the most neglected topics in Agile Projects. In an earlier article, I showed you why Risk Management is also necessary for Agile projects. In this article, you will learn how to implement Risk Management in Agile projects, and what you need to pay attention to. Every Scrum Master, Product Owner or Developer can certainly learn some helpful tips here. Sure!
In Projects Something Always Goes Wrong – Even in Agile Ones
Risk management is also a topic in agile projects—but often a neglected one! Also Jeff Sutherland (a co-founder of Scrum) made his experiences with risks and based them on a quote from General Carl von Clausewitz (Book: Vom Kriege):
As soon as you try to execute anything—even a software project—bad things happen!
He commented, “I’m sure you are familiar with such moments: There is a lot of noise and confusion; sometimes, there is smoke and fire, and communication breaks down, and everything conspires to keep you from doing things.”
In his book, Scrum: The Art of Doing Twice the Work in Half the Time Jeff Sutherland describes that Scrum projects usually involve three types of risk:
- Financial Risk—Can we pay for it?
- Business Risk—Will it be used? Does it solve the problem?
- Technical Risk—Can it be made/build? This is often, in relation to financing, when a product can be built but is too expensive.
Sutherland summarizes, “The best way to reduce risk in general is: Build potentially shippable increments for users.” But, is that really enough?
Risk Management in the Scrum Guide
The Scrum Guide does not explicitly address risk management, except for these brief references:
- The incremental approach with sprints reduces risks.
- Sprints increase predictability and limit cost risk to a maximum of one month.
- Constant “Artifact Transparency” helps optimize (business) value and reduce risks.
Is Jeff Sutherland really of the opinion that only the Agile project approach reduces risks in the best possible way? As you read in my last article, Is Risk Management Necessary in Agile Projects? Some of the risks are certainly reduced, but a large part of the risks still lurk somewhere to take you by surprise at some point.
Identifying Risks on Two Levels and at Different Points in Time
In Agile projects, you should identify risks on two levels:
- At Project Level: What risks threaten the overall project, or Epics (i.e., big user stories) of the project?
- At Requirement Level: (i.e., User Story)—What is the risk of each requirement during implementation or in operation? These include, for example, risks relating to: Feasibility, acceptance, time-to-market, costs, safety of data and people.
Even before you start a project you should roughly assess its risks—and if these are too high, terminate or reconsider the project. Another important time is the requirements workshop, which provides a more detailed risk assessment for the further procedure.
Determine Risks at Project Start, Project Kick-Off, or Requirements Workshop
At project start, project kick-off, or requirements workshop, the Product Owner should also consider the risks with the workshop participants. The participants should identify risks for the overall project, but also for the already-known requirements. Then, the Product Owner should evaluate the risks with the participants and define actions. The duration of this should be approximately 30 minutes to one hour.
Identifying Risks in Release Planning
At each release planning (i.e., medium-term planning), the Product Owner should review the risks already identified with the developers and any other stakeholders, and, if necessary, reevaluate them. If the releases contain only one or two sprints, these risk reviews should be repeated at least every 2 to 3 months, depending on the duration of the project. The duration of this should be approximately 30 minutes.
The product owner needs the risk value of a requirement because, along with the business value, the risk value is an important criterion when prioritizing the requirements to be implemented. Requirements with the highest risk are often the first to be realized, according to the motto:
Fail early; fail fast; fail cheap.
Identify/Check Risks During Sprint Planning
In the Estimation Meeting (or, at the latest, at each Sprint Planning), the Scrum team should briefly discuss/check the risks of each individual requirement again, as well as identify and evaluate any new risks, and define actions. This way, the developers are aware of the risks while implementing the user stories, and they can implement planned actions. The maximum effort for this should take 15 to 30 minutes.
The following figure shows at which points in time risk management activities make sense in a Scrum project:
- Before the actual project start (e.g., in the requirements workshop or comprehensive kick-off meeting)
- For each release planning (e.g., before each new release)
- At every Sprint Planning (e.g., at the start of every Sprint)
How to Determine the Risk Value
Here you will find a very short summary of how to describe risks and determine the risk value.
For each requirement, you should determine the risk and the risk value as follows:
- Describe the uncertainty (i.e., what could happen).
- Determine the Impact I (1=low, 5=high).
- Determine the Probability P (1=low, 5=high).
- Multiply the Impact (I) by the Probability (P) to obtain the Risk Value R=IxP.
- If possible, determine actions to reduce or eliminate the risk.
You will determine the impact and probability of the risks efficiently and without long discussions if each team member spontaneously gives his assessment by holding a card from 1 to 5 (like point judges in figure skating). Then, you can determine the approximate mean value. If a requirement has no risk, then it has the risk value “0”.
If you have identified a risk, describe it briefly on the back of the card on which the user story is written. However, it is best to record all risk data in a separate risk log. This can be a simple data table in Excel or other software..
As I said before, this was only a very brief introduction. Invest the amount of a good Starbucks coffee and order this comprehensive introduction to Project Risk Management: Project Risk Management—Compact Knowledge.
Shorter Sprints Reduce Risks
The more risks your project has, the shorter your sprints should be. Sprints in Scrum have a maximum duration of four weeks. For shorter sprints, the product owner can determine the progress of the project more frequently and take action quicker in the event of deviations from the plan. Shorter sprints of one or two weeks also have the advantage of generating more pressure, and thus, increasing the team’s focus on the work.
If you use shorter sprints, the requirements that are included in the sprint planning should be smaller and more detailed. Of course, this gives more preparation work to the Product Owner.
In general, shorter sprints mean that requirements are more quickly transformed into a shippable product increment. This also means that retrospectives are carried out more frequently, which has a positive effect on collaboration, processes, and productivity, and thus, also reduces project risks.
“The more risks your project has, the shorter the sprints should be.”
How to Carry out Risk Management Efficiently and Successfully
How Much Time Should Be Spent on Risk Management?
In the above sections, I have given the approximate duration for risk management activities in the different parts of a Scrum project. The duration is deliberately kept short. The bigger and more complex your project is, the more effort you should put into risk management. Risk management can be carried out efficiently and successfully at the same time. However, this requires some practice and experience. You will find tips on this in my books.
Who is Responsible for Risk Management?
In my opinion the Product Owner is responsible for risk management in a Scrum project. The Scrum Master is the appropriate person to establish risk management in the Scrum team. He should bring the Scrum Team to a point where they can successfully carry it out themselves over time.
Performing Risk Management Efficiently Requires Knowledge and Experience
Using risk management in projects requires a good knowledge of risk management itself (process, methods), but also practice and experience.
Only a Scrum Master, who stands behind risk management and sees value in it, can convince the Scrum team of the benefits of risk management. The Scrum Master can be of great benefit to the whole Scrum team as a coach and mentor, convincing them of risk management and training and guiding the process at the beginning. This way even agile projects become even more successful.
Pro-Tip: Start with risk management! Be convinced of the benefits. Just talking about risks in the project reduces their probability of occurrence! I wish you every success.
This was only a very brief description of risk management in Agile projects. For example, I left out the opportunities (i.e., how you correctly describe risks and define good actions).
Here You Can Find Even More Knowledge
Would you like to learn more about risk management in projects or Scrum? My books on Project Risk Management and Scrum will help you take an important step forward!
Do you know anyone who might be interested in this article? Then, simply forward or share it. Thank you!
