Download any RAID log template and you get the same four tabs. Risks, with a probability and an impact rating. Assumptions, with an owner and a date to validate. Issues, with a severity and a status. Dependencies, with the team you are waiting on and the date they said. It is a sound structure, and a release team that fills it in during planning is ahead of most. Now look for the column that says what each row is currently doing to the release date. It is not there. Not in the free spreadsheet, not in the PMO’s Confluence version, not in the one the consultancy left behind.

That gap is not a design flaw in the template. It is a timing problem. A RAID log template is a structure for recording judgment on planning day. What happens to that judgment over the twelve weeks that follow is a different job, and the template was never built to do it.

What a RAID log template is for

A RAID log is the register a project keeps of the things that could move its plan: risks, assumptions, issues and dependencies. The template gives each its own list. A risk row carries a likelihood, an impact, an owner and a mitigation. An assumption row carries the statement, who owns it and when it will be checked. An issue row is a risk that has already happened, with a severity and a resolution path. A dependency row names what is needed, from whom, and by when. Filled in at PI planning, the log is the written form of the confidence vote’s fine print: the team’s expert judgment about what could go wrong, set down so that someone owns each item. (Why the R and the D rows go stale fastest is covered in the RAID log’s refresh-rate problem.)

Hold the four columns up against the three things that quietly move a release date after the vote. Dependencies are the second of them, listed by name. The risks a release team actually writes down are nearly always scope risks (“the auth rewrite may be bigger than sized”) or capacity risks (“two seniors are up for rotation in sprint 4”), which are the first and third drivers wearing a probability score. Assumptions are the premises the vote rested on: which throughput counted as evidence, who was on the roster, where the scope boundary sat. Issues are risks that have landed. A RAID log template is, in effect, a pre-sorted catalogue of the ways a committed date could move. What it never records is how far.

The column every RAID log template is missing

Take a typical row. Risk: “Payments vendor’s sandbox may not be ready for sprint 3.” Probability: Medium. Impact: High. Mitigation: “Build against mocks; weekly check-in.” Owner: named. This is competent risk management. Now ask the one question the release manager needs answered: if this happens, what does it do to the committed date, in days, at the confidence the team voted at? The template has no cell for that answer, so nobody writes it, and “Impact: High” stands in for a number nobody has computed.

Multiply that across thirty rows. Each has a qualitative impact. None has a date impact. The log is complete and the committed date is unreadable from it. The rows also interact in ways a spreadsheet cannot see: a dependency slipping two weeks costs something different when capacity has already dropped fifteen percent, and a scope risk that materializes in sprint 5 lands on a release with far less room than it had in sprint 2. Independent scores in independent cells cannot add themselves up. Only a forecast can.

Fill the template with references, not copies

The fix does not require a new template. It requires the same move that makes a release planning template stay honest: fill each column with a reference to something live in Jira rather than a description of it.

• Risks. Every scope risk names the Fix Version items it threatens. Every capacity risk names the people and dates on the roster. When the risk materializes, the evidence appears where the forecast is already looking: scope grows, or throughput dips, without anyone editing the row.
• Assumptions. Record the throughput window the vote was built on, the capacity roster and time off it assumed, and the Fix Version boundary it treated as scope. These are the team’s decisions and they stay the team’s decisions; the point is that they are recorded as the inputs they are, so an expired assumption is visible as a change in an input rather than as a sentence nobody re-read.
• Issues. An issue is a blocked or impaired item in the release. Flag it in Jira on the Fix Version item it affects. Blocked items stretch cycle time, and stretched cycle time is exactly what a throughput-based forecast reacts to.
• Dependencies. Make each one a Jira issue link, hard or soft, to the upstream item, including a placeholder item for anything that lives in a vendor’s backlog. Linked dependencies sit on the dependency graph and the critical path, so when the upstream date moves, the forecast moves with it.

Then read the missing column off the band

With the columns pointing at live objects, the column the template lacks can be generated rather than typed. Advanced Release Planning holds the committed date together with the confidence level the team voted at, 50, 85 or 95 percent, and runs a Monte Carlo forecast on the team’s own throughput. The team still owns every assumption in the A column: which throughput window counts, whose capacity is on the roster, what is inside the Fix Version. The app owns the recalculation. When a linked dependency’s date slips, when an item is added to the Fix Version, when someone’s allocation changes, the band moves, and the movement is recorded in days and attributed to scope, dependency timing or capacity.

That attribution is the RAID log’s missing column, kept live. The risk row’s “if this happens” becomes “this is happening, and it has cost six days at P85,” on the day it starts happening rather than at the next fortnightly review. The dependency row’s “by sprint 3” becomes a critical-path position that is either holding or is not. And when the accumulated movement pushes the committed date below the confidence the team chose, the release moves from on-track to attention while there is still scope, sequence or capacity to trade. That is the renegotiation the RAID log was always meant to enable, arriving before the slip instead of documenting it afterward.

Nothing here replaces the team’s judgment or the register. The confidence vote was the right call on the evidence available; the RAID log is the right record of what the team saw coming. The app does not store a RAID log, has no risk register or issue log of its own, and leaves your template wherever you keep it. What it supplies is the reading the template cannot: the current cost, in days, of every row that has started to come true. The specific fields each RAID column should reference are set out in the committed-date how-to.

Keep the register. Add the reading.

Keep the RAID log. It is the most honest document a release produces, because it is the team saying out loud what could go wrong. Then put the committed date and its confidence band beside it, so every row is priced in days when it lands and re-priced as the release moves. See how Advanced Release Planning keeps a committed date live in Jira, and let the next risk be renegotiated before it slips the date, not explained after.

Frequently asked questions

What should a RAID log template include? Four lists. Risks (statement, likelihood, impact, owner, mitigation), assumptions (statement, owner, date to validate), issues (statement, severity, owner, resolution) and dependencies (what is needed, from whom, by when, status). For a release with a committed date, add a fifth reading rather than a fifth column: the current position of the committed date against its confidence band, with the movement since the vote attributed to scope, dependencies and capacity.

How is a RAID log different from a risk register? A risk register covers risks alone. A RAID log adds the assumptions the plan rests on, the issues that have already occurred, and the dependencies on other teams or vendors. For release planning the wider scope matters, because dependencies and expired assumptions move committed dates at least as often as the risks anyone scored.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio