Risk in Scrum: from a vague worry to an ordered backlog

Every project has a list of things people are privately worried about: the vendor that has not yet delivered, the integration nobody has tried, the key person who might leave. In a lot of teams that list lives in heads. Scrum's contribution is to make risk part of how work is chosen and not a separate document that someone updates before a steering meeting.

Short cycles are the main control

The Scrum Guide does not have a risk chapter, but it states the mechanism early. Scrum employs an iterative, incremental approach to optimise predictability and to control risk. A Sprint is at most a month. Each Sprint may be considered a short project, and shorter Sprints can be used to generate more learning cycles and limit the cost and effort at risk to a smaller time frame. When a Sprint's horizon is too long, the Guide warns, complexity may rise and risk may increase.

The SBOK® Guide says the same thing in its own words: the iterative nature of Scrum, with its rapid turnaround time and feedback cycles, allows early detection of failures, and so it has a natural mitigation feature built in.

That is the foundation. A team that releases something usable every two weeks finds out quickly whether its assumptions are wrong. Everything else in this post is refinement.

Risks and issues

The SBOK draws a clean distinction that is worth borrowing.

• A risk is an uncertainty about the future that could change the outcome, for better or worse. It has no impact yet.
• An issue is a certainty that is happening now. There is nothing to assess, and it must be dealt with.

"The payment provider might take longer to approve our account" is a risk. "The payment provider has not approved our account and we need it tomorrow" is an issue. Risks that are not addressed in time can become issues, and the aim of managing them is to have a plan before that happens. Impediments, which the team tracks day to day, are mostly issues. See impediments and the impediment log.

The SBOK's five steps

The SBOK describes risk management as five steps, repeated throughout the project: identify, assess, prioritise, mitigate and communicate.

Identify. Look for what could affect the project, from several angles. The SBOK suggests reviewing lessons learned from earlier Sprints and releases, checklists of common risks, prompt lists that stimulate ideas, brainstorming with stakeholders, grouping risks in a breakdown structure such as financial, technical and safety, and interviews with people who know the area.

Assess. Rate each risk on probability, how likely it is, proximity, when it might occur, and impact, how bad it would be. The SBOK describes several techniques, among them a risk meeting where the core team ranks risks by subjective judgement, and a probability and impact grid, where each risk is given a rating for each factor and the two are multiplied into a severity score. Its example is a probability of 0.5 and an impact of 0.6 giving 0.3. Risks with both high probability and high impact come first.

Prioritise. Decide which risks to act on and put them in the backlog. This is the Scrum-specific step, covered below.

Mitigate. Choose a response: reduce the probability, reduce the impact, plan a fall-back, or accept it. The SBOK notes that acceptance is a legitimate response when probability or impact is too low to justify action.

Communicate. Tell the stakeholders the potential impact and the plans for each risk. The SBOK says this happens in parallel with the other four steps and not at the end.

Nothing here requires special software. A shared table with columns for risk, probability, impact, owner and response is enough for most teams.

Putting risk into the backlog

The distinctive idea is how risks join the plan. The SBOK says identified risks are taken into account when the Prioritized Product Backlog is created and when it is refined, so the backlog may be called a risk-adjusted backlog. The mitigations the team will take are added as user stories and prioritised alongside the rest.

That is the same logic described in ordering the Product Backlog, where risk is one of three ordering factors. A risky story goes earlier so the team learns sooner whether it is possible. A mitigation that is itself a piece of work, such as "get the payment account approved" or "try the integration with a test file", is a backlog item with a place in the order.

The Scrum Guide does not use the word risk here but has the same instinct: the Product Owner orders the backlog, and the order carries the team's best judgement.

Spikes

The SBOK describes a risk-based spike: a short experiment of research or prototyping, intense and typically two to three days, to understand a potential risk better. It suggests running one early, before epics are developed or the backlog is created, particularly when the team is new to a technology or when stories are large. Spikes can also occur during any Sprint, and they belong on the backlog.

A spike has a question, a time limit and an output that is knowledge, not product. "Can we create a booking through the provider's test interface in under two days of effort?" is a good spike. When it ends, the team knows whether the risk is real, and plans accordingly.

Who owns risk

In the SBOK, the Product Owner is responsible for risks related to business aspects, and the team for carrying out the risk responses during the Sprint. The Scrum Master keeps a close eye on potential risks and keeps the Product Owner and team informed. The Scrum Guide does not assign risk to a role, but its accountabilities cover the same ground: the Product Owner orders the backlog, the Developers plan the Sprint, and the Scrum Master helps the team be effective.

A worked example

An invented case. A team building a booking system lists five risks and rates each on a 0 to 1 scale.

Two items clearly come first: the provider approval and the page usability. The team adds two backlog items: "request the provider test account today" and "run a quick usability check on the booking page after the first Sprint". It decides to accept the hosting cost risk and review it each month. The other two are watched.

Common mistakes

• A risk list nobody reads. If it is not part of ordering and planning, it is a document.
• Rating everything high. A grid where every item is red tells you nothing.
• Confusing risks and issues. The responses are different.
• No owner. Each risk needs one person who checks it.
• Mitigations that are not work. If a response is not in the backlog, it will not be done.
• Treating the risk list as permanent. Risks change as the work does. Revisit it at each Sprint Review.

The Agile Manifesto's principle that agile processes harness change for the customer's competitive advantage is the positive side of risk: uncertainty can be an opportunity as well as a threat, as the SBOK also notes.

How to practise it

In the simulator, the backlog is ranked by value and risk at the first phase's fifth step, and risks and impediments surface during each Sprint. Your handling of them carries forward into later Sprints.