Key Takeaways
- A risk register is expert judgment written down: what could go wrong, how likely, how bad, who owns it, what the team will do.
- It scores risk on a grid. It never says how many days a materialising risk costs the committed release date.
- Most schedule risks land in Jira as one of three things: a late dependency, added scope, or a capacity change. Those can be read in days.
- Keep the register. Add one number to every review: the gap between the committed date and today’s forecast at the confidence the team voted at.
The risk review runs on the first Tuesday of the month. Row 7 says “Platform team API change may slip — Likelihood 3, Impact 4, Score 12, Owner: Priya, Response: Mitigate.” It said the same thing last month. The colour is still amber. Nobody in the room can say whether row 7 has already moved the release date, or by how much.
That is not a failure of the people. The risk register did exactly what it was built to do. It just was not built to answer the question the release depends on.
What a risk register is good at
A risk register is a table of identified risks. The usual columns are ID, description, likelihood, impact, a score (often likelihood × impact on a 1–5 grid), owner, response and status. A project risk register is where a team’s experience gets written down before it is needed: the vendor that has slipped before, the shared service with no spare capacity, the integration nobody has tested end to end.
That is expert engineering judgment, and it is the same judgment behind the team’s confidence vote at planning. The register ranks what deserves attention. It assigns an owner so a risk is not everyone’s problem and therefore no one’s. None of that should be replaced.
What it cannot tell you
A score of 12 is a rank, not a duration. The register can say row 7 matters more than row 9. It cannot say whether row 7, now partly materialised, has pushed the committed date out by six working days and dropped its confidence from 85% to roughly 60%.
Two structural limits cause this. First, the register is true as of its last edit, and it is edited on a meeting cadence. Second, it records the risk, not its effect. When a risk materialises, it stops being a row and becomes work: a blocking link, new tickets, a person moved to another team. The register keeps the old score while the date moves underneath it.
Where register risks actually land
Look at any release retrospective and most schedule risks trace back to the three things that erode a committed release date after the vote:
- Dependencies surfaced too late. The “may slip” row becomes a hard blocking link on the critical path.
- Scope creep. The mitigation plan is new work. A “Mitigate” response adds tickets to the Fix Version, and those tickets consume throughput like any other.
- Capacity changes. The key-person risk becomes a real absence, a reallocation or a holiday nobody counted.
Each of these leaves a trace in Jira. That trace can be read against the committed date in days, continuously, without waiting for the next review. The same pattern applies to a SAFe ROAM board: naming a risk is not pricing it.
Add one column: days against the date
Keep the register. Change what the review opens with. Before walking the rows, read one number: the gap between the committed date and today’s forecast at the confidence level the team committed at.
An illustration: a team commits to 14 November at 85% confidence. Three weeks later the register is unchanged, but the platform dependency is now a hard blocking link and two mitigation stories have joined the Fix Version. The forecast at 85% now reads 24 November. The gap is ten days. Row 7 is still amber on the grid; on the calendar it is the reason the date no longer holds.
That turns the review from “is this still amber?” into “what are we cutting, re-sequencing or renegotiating to close ten days?” It is the same discipline behind a RAID log template with a days column: every row is judged against the date, not just the grid.
How Advanced Release Planning keeps it live
Advanced Release Planning for Jira does not store or score your risk register. The team still owns the assumptions: which throughput window to trust, whose capacity is in, what is in scope. The app does the arithmetic at Monte Carlo scale over the team’s real Jira throughput and keeps it current.
- The committed date carries a live confidence band: 50%, 85% and 95%.
- Dependency-aware forecasting reads Jira links, hard or soft, and the critical path. A risk that becomes a blocking link moves the forecast.
- Mitigation work on the Fix Version is counted as scope, not as a risk allowance.
- Capacity changes flow into available throughput, so the forecast moves when people do.
A step-by-step for pairing the two is in the Risk Registers & the Committed Release Date reference.
The register tells the team which risks deserve attention. The forecast tells them what the risks that already happened have cost. With both, the team renegotiates before the date slips, not after.
FAQ
What should a project risk register include?
At minimum: ID, description, likelihood, impact, score, owner, response and status. For a release, add the date each risk was last reviewed and, at every review, the current gap in days between the committed date and the forecast.
Can a Monte Carlo forecast replace a risk register?
No. The forecast does not know about risks that have not materialised, and it does not rank them. The register holds the team’s judgment about what could happen; the forecast reads what has happened to the committed date.
See your committed date and its live confidence band in Advanced Release Planning, or view it on the Atlassian Marketplace.
