How to write a risk or issue
A risk might hurt delivery. An issue is hurting delivery right now. The RAID log is where both live.
- steps
- 9
- named failure modes
- 5
- definition-of-done criteria
- 6
How to write a risk or issue, in one paragraph
A risk is something that might reduce an outcome's value or move its date. An issue is something already doing it. Both are written the same way: one sentence of cause, event and consequence, attached to one epic, priced in currency, owned by one named person, with a date by which a decision has to be taken. Written well, a stranger can read it and act. If you cannot say what value is exposed and by how much, you have written a worry, not a risk.
What these are. The delivery operating model our engagements install alongside client teams: the method underneath the agentic work rather than the agentic work itself, published in full and free to use. It is written for the person running a quarter, not for a buyer, so if you are evaluating us, read the five priced engagements or the case studies instead.
The moment you spot something that could move a date, a number or a scope and you cannot resolve it inside the day. Also the moment an assumption you were relying on turns out to be false, whether or not it has cost you anything yet.
- Time to run it once
- About forty-five minutes, per entry
- What you need
- The RAID log
- The epic the item attaches to
Step by step
Each step is deep-linkable, so you can send a colleague the one that is in dispute.
- 1
Classify it: risk, issue, bug, debt or dependency
Classify it first.
Ask whether the damaging event has happened yet: if it is ahead of you it is a risk, if it is costing time, money or scope now it is an issue. A defect in something already shipped is a bug and links to the quarter's Bug Budget epic. A shortcut that will slow you later is tech debt and links to the Tech Debt epic. Something another team owes you on a date is a dependency. Something you are relying on and cannot prove is an assumption. If it is work with an obvious owner and takes under a day, do it instead of logging it.
- 2
Write it as cause, event, consequence
Write one sentence in three parts: because [something verifiable that is true today], [event] may happen, which would [effect on the epic's value or its date]. For an issue, change the tense: because X, Y has happened, and it is costing Z. The cause has to be a fact someone could check, not a feeling. Test it by reading it to a person outside the team. If they cannot tell whether the event has already happened, or what it costs, rewrite it. Noun titles like vendor risk or resourcing risk give a reader nothing to decide on.
- 3
Attach it to exactly one epic
Attach every item to exactly one epic, or to the outcome above them when the threat spans several epics.
Do not clone one risk across three epics: raise it once at outcome level with the aggregate exposure, or you will count the same money three times when you rank the log. The link is what lets a reader trace from the item to a currency target in one step, and it decides who reviews it and which quarter it sits in. If there is no live work to attach it to, it belongs on the company-level log, or it is an assumption rather than a risk.
- 4
Price the exposure in currency
Two numbers, then multiply.
Value at risk is the share of the epic's planned contribution that is threatened, which is rarely all of it: a one-quarter delay to a £400k epic exposes roughly a quarter of the annual benefit, so write £100k and record the assumption behind it so someone can argue with it. Probability is your honest estimate in tens, because 65% persuades nobody. Exposure is the two multiplied. Sort the log by exposure and compare the top three against the epics they threaten. Anything worth less than a couple of percent of the outcome target gets logged and then left alone.
- 5
Name one owner and a decide-by date
Name one person, never a team and never a role.
The owner is whoever can make the call, which is usually not the person who spotted it: if the response needs budget or a supplier conversation, the owner is the person holding the budget or the relationship. Then set the decide-by date, the last day on which a decision still changes the result. Work it back from the release window and from roadmap close, because an epic ships in one quarter and a decision taken after close has made itself. If the decide-by date passes, record which default you took and why.
- 6
Choose a response and one next action
For a risk, choose one of avoid, reduce, transfer or accept, and write the choice down.
For an issue, choose contain, fix or replan. Then write exactly one next action with a name and a date on it, not three. Two rules keep this honest. A mitigation that costs more than the exposure is not a mitigation, so price the response before you commit to it. And accept is a real answer: a log where nothing is ever accepted is a log where everything is being quietly mitigated by nobody, which is how twenty amber items survive a whole quarter.
- 7
Book the review point when you write it
Give the item a review point at the moment you write it, or it gets reviewed when somebody happens to remember.
Decide-by date inside two weeks: it joins the daily lookahead. Threatens the value of a live outcome: it goes into monthly outcome validation, where that number is being tested anyway. Everything else waits for roadmap close, where each open item is either carried into the next roadmap with a fresh decide-by date or closed. Patterns across items, such as the same supplier appearing four times, belong in the retro rather than in the log.
- 8
Escalate by moving a number, not a colour
Escalation is a number moving where people outside the team can see it, not an email with a colour on it.
If the response is to descope, cut the epic's planned contribution and let the hole show against the outcome's target so somebody owns it. If the response is to move the work, the epic leaves this quarter's roadmap, because an epic lives in exactly one quarter. If the response is more people, name what leaves the roadmap to pay for them. Apply the test before you send anything: which number moved, and on whose screen?
- 9
Close it with a reason
Close every item with one of four reasons: the event happened, the event can no longer happen, we accepted it, or it was never real.
Then record what happened to the exposed value: landed, partly landed, or lost. That second note is why the log is worth reading next quarter, because the pattern across closed items tells you which risks your organisation habitually underprices. Record it where the answer is embarrassing, especially there. Count closures at roadmap close: a log that closed fewer items than it opened all quarter is an archive, not a management tool.
Worked example: a payment SDK deprecation
Ravensworth Home is an invented online homeware retailer, and every number below is invented with it. Its outcome for the year is Reduce checkout abandonment, with a target of £1.2m in recovered revenue. One epic on the Q3 roadmap, One-page checkout, carries a planned contribution of £400k. In week two of the quarter the tech lead sees that the payment provider has announced the current SDK will stop accepting new integrations from 1 September, and the replacement sandbox has not been granted. Written up, it reads: because the payment provider closes the current SDK to new integrations on 1 September and we still have no sandbox access, the one-page checkout epic may not be releasable this quarter, which would push £400k of planned contribution into Q4. Value at risk is not £400k. A one-quarter delay costs a quarter of the annual benefit, so the team writes £100k and notes the assumption next to it. Probability, honestly, 60%. Exposure is £60k, which puts it second on a log of six items and above the three the team had been talking about most. The owner is the named engineering manager who can call the provider's account team, not the checkout squad. Decide-by is 8 August, because integrating and testing against a new sandbox takes six weeks and the last release window of the quarter is mid-September. The response is reduce, with one action: obtain sandbox credentials or written confirmation of an extension by 8 August, fallback of descoping to the existing SDK. On 8 August there is no answer, so the owner records the default taken and starts the fallback. On 12 August the provider confirms no sandbox until October. The risk becomes an issue on the same record, keeping its history, and probability stops mattering: the £100k is exposed. The team replans, cuts the epic's planned contribution from £400k to £300k, and the roadmap now shows a £100k gap against the £1.2m target in week seven of the quarter rather than in the last week. At roadmap close it is closed with reason: the event happened, value partly landed. The return on writing it properly in week two is nine weeks of warning.
Where this goes wrong
- 01
Tasks wearing a risk label.
"Risk: we have not hired a second tester" is a piece of work with an owner and a date, not a risk. It gets logged because nothing gates the log, and it crowds out the two items that needed a decision from someone senior.
- 02
Red, amber and green instead of currency.
Colours cannot be summed, ranked against an epic's planned value or compared with last quarter, so every review turns into an argument about whether something is amber. An exposure figure ends that argument in one line.
- 03
Value at risk set to the whole epic.
Copying the full epic value into every item makes the log read as catastrophic and makes ranking impossible, so nothing gets prioritised. Most threats cost a share of the benefit, usually a delay's worth, and the arithmetic takes a minute.
- 04
Ownership handed to a team.
A risk owned by "platform" is owned by nobody. It gets discussed for six weeks without resolution, because no individual has been asked to decide and no individual is uncomfortable that it is still open.
- 05
An issue that changed nothing.
If raising it did not move a date, a scope or a planned contribution, it was a status update. Either the response was never chosen or the escalation stopped at a slide, and the quarter ends with the same number it started with.
Done means
- One sentence in cause, event, consequence form that a reader outside the team can act on without asking whether it has happened yet
- Linked to exactly one epic or outcome, with no duplicate copies of the same threat across sibling epics
- Value at risk, probability in tens and exposure all recorded, plus the assumption behind the value at risk
- One named person owns it, and the decide-by date falls before the release window and before roadmap close
- A response chosen from the four (or contain, fix, replan for an issue) and exactly one next action carrying a name and a date
- A review point set: daily lookahead, monthly outcome validation, or roadmap close
AI-augmented teams tend to surface risks during refinement and mid-build, when a story turns out to be bigger than it looked. AI-native teams have no stories, so items attach to the outcome ticket at epic level, and the risk classes shift. Watch for three in particular: test requirements that were never defined precisely enough for anyone to prove the outcome is met, completion reported by a model with no demonstrated user journey behind it, and supply risks with real dates on them such as model deprecations, context or rate limits, and provider pricing changes. Agents also generate candidate risks faster than a team can read them, so gate the log on exposure and keep the owner human. A model can draft the cause, event, consequence sentence and do the delay arithmetic; it cannot hold the decide-by date.
The two delivery modes, side by side →Questions
When a risk becomes an issue, do I raise a new item?
No. Change the type on the same record so the history stays attached: the original cause, the decide-by date, the response you chose and the date it converted. Probability stops applying, because the event has happened, so the value at risk becomes the exposure. Raising a fresh item hides how long you knew, which is the part worth learning from at roadmap close.
How do I set a probability when I have no data?
Ask how often this has happened to you before in similar circumstances, and start there. Estimate in tens, get a second person to write a number down independently before either of you speaks, and take the higher one if they disagree by more than twenty points. You are not trying to be right to the percentage point. You are trying to rank this item honestly against the other things on the log.
Our board wants a RAG status. Do we abandon that?
Keep the colour as a presentation layer and derive it from the exposure, for example red above a set share of the outcome's target, amber above a lower one. Nobody argues about a band that a formula produced. What you should not do is store the colour as the underlying record, because then the number that lets you rank and compare no longer exists.
How big should a RAID log be?
Small enough to review every open item at roadmap close in an hour. If it is bigger than that, the entry bar is too low: items with an exposure under a couple of percent of the outcome target are recorded and left alone rather than managed, and anything that is work with an owner and a date belongs in the backlog instead.
More on writing the work
These guides are written to be read in order.
How to write a story
A good story is small enough to build in a sprint, specific enough to test, and honest about the assumptions it carries.
How to write a chapter
A chapter is what a developer creates when a story turns out to be bigger mid-build. A tactical sub-task, not a user-visible slice.
How to raise a bug
A bug is a defect in something already shipped. If it is a missed requirement, it is a story, call it what it is.
Want help installing this?
These guides are free and you owe us nothing for using them. If you would rather have operators install the operating model alongside your teams and stay until it sticks, that is what our engagements do.
Most organisations start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks