ROAM in 60 seconds
- ROAM stands for: Resolved, Owned, Accepted, Mitigated.[1]
- When: on day two of PI Planning, after the final plan review and before the confidence vote.
- What gets ROAMed: risks the teams could not deal with themselves. SAFe calls these ART PI Risks.[2]
- The point: every risk leaves the room with a decision and, where needed, a name.
- The trap: ROAMing once and never looking at the board again.
What is ROAM in SAFe?
ROAM is a technique for dealing with risks during PI Planning. Each risk that could affect the plan is discussed openly and placed in one of four categories: Resolved, Owned, Accepted or Mitigated. It turns a list of worries into a list of decisions.
SAFe defines ART PI Risks as "identified items that could impact the ability to meet the ART's PI objectives."[2] During planning, teams raise the ones they cannot handle alone, and the whole train works through them together. The four categories come from Scaled Agile's PI Planning guidance, which describes risks being "categorized into one of the following categories" in what it calls "the ROAMing exercise."[1]
A note on sources. The four definitions below are quoted from an archived version of Scaled Agile's PI Planning article, because the current public pages do not spell them out. Other websites paraphrase ROAM in slightly different ways, so if your organisation has agreed its own wording, use that consistently.
For context, the general definition of risk used in international standards is the "effect of uncertainty on objectives."[3] The Association for Project Management adds that risk "can be perceived either positively (upside opportunities) or negatively (downside threats)."[4] ROAM, as used in PI Planning, deals with threats to the plan.
What do Resolved, Owned, Accepted and Mitigated mean?
Resolved means the risk is no longer a concern. Owned means someone takes responsibility for it after the event. Accepted means it is understood and the train will live with it. Mitigated means there is a plan to reduce its impact.
| Category | Scaled Agile's definition[1] | What happens next |
|---|---|---|
| Resolved | "The teams agree that the risk is no longer a concern." | Nothing. Remove it from the list. |
| Owned | "Someone on the train takes ownership of the risk since it cannot be resolved during PI planning." | The owner works on it and reports in the next ART Sync. |
| Accepted | "Some risks are just facts or potential problems that must be understood and accepted." | Record it and watch for the trigger. |
| Mitigated | "Teams identify a plan to reduce the impact of the risk." | The mitigation becomes planned work with an owner. |
The order is a useful sequence of questions. Can we resolve it now? If not, who will own it? If nobody can do anything, do we accept it? If we can reduce the damage, what is the plan?
How do you run a ROAM session in PI Planning?
Collect the risks from every team, read each one out, let the train discuss it briefly, agree a category, and write down the owner and next step. Keep each risk to a few minutes. The Release Train Engineer facilitates.
- Collect during breakouts. Teams note risks as they plan. They deal with team-level risks themselves and pass up the ones that need the train.
- Write each risk clearly. "If X happens, then Y, which affects Z." A risk without a consequence cannot be discussed.
- Group and remove duplicates before the session.
- Present one at a time. The team that raised it explains it in a sentence or two.
- Ask the four questions in order: can we resolve it now, who owns it, do we accept it, how do we mitigate it?
- Record the decision where everyone can see it: category, owner, target date, and the features it affects.
- Move on. If a risk needs a long discussion, give it an owner and take it offline.
- Go to the confidence vote. Unresolved risks are a main reason for low votes, so the two belong together.
Tip from the fieldAn owner is a named person in the room who says yes out loud. "The platform team" or "management" is not an owner.
What do ROAMed risks look like in practice?
Good risk statements name the cause, the consequence and what is affected. The examples below show one risk in each category.
| Risk | Category | Why, and what happens next |
|---|---|---|
| If the test environment is not ready by iteration 2, integration testing slips. | Resolved | The infrastructure lead confirms in the room that it is booked for iteration 1. |
| If the security review takes more than two weeks, the payments feature misses the PI. | Owned | The System Architect takes it, meets security this week and reports at the next ART Sync. |
| A key engineer is on parental leave for iterations 3 and 4. | Accepted | It is a fact. The team has planned its capacity around it. |
| If the supplier API is late, checkout cannot be completed. | Mitigated | The team will build against a mock and has a fallback release without the new provider. |
What should a ROAM board template contain?
A ROAM board needs, for each risk: a clear statement, the category, an owner, a target date, the teams and features affected, and the agreed action. A simple four-column board works in the room. A register works better afterwards.
| Field | Why it is there |
|---|---|
| Risk statement | Cause, consequence and what is affected, in one sentence. |
| ROAM status | Resolved, Owned, Accepted or Mitigated. |
| Owner | One named person. |
| Target date | When the owner will report or the mitigation will be in place. |
| Affected teams and features | So the impact on the plan is visible. |
| Probability and impact | Optional. Useful for ordering a long list. |
| Action or mitigation | What will actually be done. |
| Raised by and date | For follow-up and for Inspect and Adapt. |
If you rate probability and impact, a risk matrix "is used during risk assessment to define the level of risk by considering the category of likelihood... against the category of consequence severity."[5] Keep it coarse. Three levels of each is enough for a planning event.
What happens to ROAMed risks after PI Planning?
Owned and Mitigated risks are reviewed at every ART Sync until they are closed. Accepted risks are watched. New risks that appear during the PI are added and ROAMed the same way. At Inspect and Adapt, the train looks at which risks materialised and why.
- Weekly: the RTE goes through open Owned and Mitigated risks by target date.
- When a date passes: the owner says what happened. A risk whose date keeps moving needs escalating.
- When a risk happens: it becomes an issue or impediment and is handled as one.
- New risks: added as they appear. The board is not frozen at planning.
- At Inspect and Adapt: review what happened to each. Risks that were Accepted and then hurt are the ones to learn from.
How is ROAM different from a traditional risk register?
ROAM is a facilitation technique for a group. A risk register is a record. ROAM decides what to do about each risk in a few minutes with everyone present. A register keeps track of it afterwards. Most trains need both, and the ROAM status is one column in the register.
| ROAM | Traditional risk register | |
|---|---|---|
| What it is | A way of deciding, together | A way of recording |
| When | During PI Planning, then in the ART Sync | Continuously |
| Who | The whole train | Usually a project or risk manager |
| Output | A category and an owner | Probability, impact, score, response |
| Strength | Fast, visible, shared commitment | Detailed, auditable, long-lived |
What are the common ROAM mistakes?
Vague risk statements, owners who are teams or departments, using Accepted to avoid a hard conversation, mixing up risks and issues, and never revisiting the board.
- Vague risks. "Performance" is a topic. "If response time exceeds two seconds at launch, the retailer will not go live" is a risk.
- No real owner. A group cannot own a risk.
- Accepted as an escape. Accepting is a decision that nothing can be done, not a way to end the discussion.
- Issues on the risk board. If it has already happened it is an impediment. Deal with it now.
- Team risks escalated. Only bring what the team cannot handle.
- One-off exercise. The value is in the follow-up.
Put this into practice, free for 6 months
Kendis is a PI Planning and tracking platform that sits on top of Jira and Azure DevOps. The free trial runs for six months, long enough to plan and track two full PIs with your real backlog before anyone has to approve a budget.
- 6 months free, no credit card
- Choose EU hosting (OVHcloud, Frankfurt) or US hosting (AWS)
- Planning board, dependencies, PI objectives, ROAM risks, solution boards
- Two-way sync with Jira Cloud, Jira Data Center and Azure DevOps
- ISO/IEC 27001 certified, GDPR compliant, DORA Schedule available
- No user caps and no setup costs during the trial
One trial per organisation that has not used Kendis in the last twelve months. After the trial, Premium Cloud is $14 per user per month billed annually, or $16 monthly, and you license only the people who plan. SSO, Kendis AI and premium support are part of paid plans. See pricing and the free trial terms.
ROAM: frequently asked questions
What does ROAM stand for?
ROAM stands for Resolved, Owned, Accepted and Mitigated. It is the set of categories used to handle risks at the end of PI Planning in SAFe.
What is the difference between Owned and Mitigated in ROAM?
Owned means a named person takes responsibility for a risk that cannot be resolved during planning. Mitigated means the teams have identified a plan to reduce the impact of the risk.
When does ROAMing happen in PI Planning?
On the second day, after the final plan review and before the confidence vote. Risks the teams could not resolve themselves are discussed in front of the whole train.
Who facilitates the ROAM session?
The Release Train Engineer facilitates. The team that raised each risk explains it, and the train agrees the category and owner.
What is a ROAM board?
A ROAM board is a board with four columns or quadrants, Resolved, Owned, Accepted and Mitigated, on which each risk is placed. Digital versions add an owner, a target date and links to the affected features.
What is the difference between a risk and an issue?
A risk is something that might happen and would affect the plan. An issue or impediment has already happened. Risks are ROAMed. Issues are dealt with immediately.
How often should ROAMed risks be reviewed?
Owned and Mitigated risks should be reviewed at every ART Sync until they are closed, and all risks should be looked at again in Inspect and Adapt.
Sources
Every external claim in this guide links to the primary source below. All links were checked on 12 October 2026.
- Scaled Agile, Inc.. PI Planning (archived SAFe 5 version, last updated 10 February 2021).
- Scaled Agile, Inc.. SAFe Glossary.
- NIST Computer Security Resource Center. Glossary: risk.
- Association for Project Management. What is risk management?.
- Wikipedia. Risk matrix.
How this guide is maintained: definitions are checked against the framework pages and other primary sources listed above, and the guide is updated when terminology or guidance changes. Examples, checklists and practical advice are Kendis guidance and are not official SAFe material. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.