Key Takeaways
- A ROAM board is expert engineering judgment, recorded well: it captures which risks a team considers Resolved, Owned, Accepted or Mitigated on planning day.
- Every column records a risk’s status. None of them records its consequence in days against the committed release date.
- Each letter has a quiet failure mode after the vote — Mitigated adds scope, Owned becomes a late dependency, Accepted arrives as unplanned work.
- Re-ROAM on a cadence and read the consequence against a live 50/85/95% confidence band, so a materializing risk becomes a renegotiation instead of a surprise.
It is the last hour of PI planning. The stickies are on the wall in four quadrants, the Release Train Engineer is working the room, and every risk anyone raised has been given a letter. Resolved. Owned. Accepted. Mitigated. Then the teams vote confidence, the hands go up, and the increment starts moving.
Week seven. The vendor API that everybody Accepted does exactly what everyone was afraid it would do. In the stand-up someone asks the reasonable question: how much did that just cost us? Somebody pulls up the board. It still says Accepted. It said Accepted in week one, too.
The ROAM board is one of SAFe’s better ideas
Give the practice its due, because it earns it. Most organizations carry risk as a feeling and a long list nobody grooms. A ROAM board forces a decision on every item. Resolved means we looked and it is not a threat. Owned means it is open and a named person is accountable. Accepted means we cannot do anything about it and we are going anyway. Mitigated means we have a plan, and the plan costs something.
That is an honest hour of work, and it happens in the same session as the confidence vote — the room names what could go wrong, then puts a number on how likely it is to hit the date anyway. Both are expert judgment. Both are also snapshots, true on the afternoon they were taken. The assumption log has the same problem: the recording is excellent, the re-reading never happens.
Four letters, four expiry dates
Nothing on a ROAM board stays true by itself.
Resolved was resolved on planning day. Risks re-open. An architecture decision gets revisited; a “we checked, it’s fine” turns out to have been checked against the old spec.
Owned is a name, and a name is a capacity assumption. The owner gets pulled onto a production incident or rolls off the train, and the risk is nominally owned and actually unattended. Nothing on the wall changes color when that happens.
Accepted is the most expensive letter on the board, because accepting a risk creates no schedule allowance at all. It is an agreement to absorb something the plan did not budget for. When it lands, it lands as unplanned work against capacity that was already committed.
Mitigated looks like the safest letter and quietly costs the most up front. A mitigation is work. You bought insurance with days out of the same Fix Version everything else has to come out of. That is often a good trade. It is rarely a re-priced one.
The board records status. The date needs consequence.
Every quadrant is a state. Not one of them is a number of days.
Which is a shame, because a ROAM board is a remarkably complete register of exactly what erodes a commitment. Line the letters up against the three things that erode a release date and they match almost perfectly. Mitigated risks are scope creep with a good reason. Owned risks are the dependencies that surface too late, sitting on somebody else’s critical path. Accepted risks are capacity change waiting for a trigger. The room wrote down all three killers the day before they started working — and wrote them down in a unit nobody can act on.
“The risk we Accepted materialized” is a status update. “The risk we Accepted materialized, and the 85% date moved out six days” is a decision.
Keeping the ROAM board live
Advanced Release Planning does not store your ROAM board, and it will not tell you which risks matter — that judgment belongs to the team and it should stay there. What it does is read the Jira state a risk produces when it materializes, and report the movement against the committed date in days. An Owned risk that becomes a blocking issue link shows up in the critical path. An Accepted risk that arrives as three new issues on the Fix Version shows up as scope. Monte Carlo simulation over the team’s actual throughput re-forecasts the 50/85/95% band continuously, so the cost of a risk landing appears in the week it lands, not in the retrospective. See how ROAM state maps to the forecast in the docs.
Four habits that make it stick
- Re-ROAM at every iteration boundary. Ten minutes is enough. Anything still Owned by someone who has left the train is not Owned.
- Link every Owned risk to a Jira issue. Dependency state is only readable if the blocking relationship is recorded as a link. An owner’s name in a spreadsheet forecasts nothing.
- Give Accepted risks a days figure. Not a probability — a consequence. “If this lands, it is roughly a week” is the sentence that turns accepting it into a real decision.
- Re-price mitigation as scope. When mitigation work goes onto the Fix Version, look at what it did to the band before you call the risk handled.
A premortem asks what could go wrong. A ROAM board decides what to do about each answer. Both are good practice, and both stop paying rent the moment the increment starts moving. Keep the letters. Add the days.
See what your risks are costing your committed date, in days, on a live confidence band in Jira.
Leave a Reply
Your email is safe with us.