Deferred risk record template
Shipping with a known gap is a legitimate decision when someone with the authority to take it has seen what could go wrong. This record is what they sign up to.
Use one record per deferral, and list them in the readiness note or the UAT pack. When the review date arrives, the deferral is either fixed, renewed by the same person, or escalated.
DEFERRAL <id>
Journey: <which journey, in the business's own name for it>
Severity: <level>, deferred
Gap: <what happens, set against the criterion or expectation it fails>
User impact: <who meets it, how often, what it costs them>
Workaround: <steps a real user can take>
Who tells them: <Support / release notes / account manager>
Accepted by: <name, role> for <this release only / until date>
Fix target: <release>, named by <Engineering lead>
Watch: <what is monitored after release, and by whom>
Review: <date, or the release at which this acceptance runs out>
If it happens in production: <who is told, what Support says>Free to use and adapt. No sign-up, no attribution needed.
How to use it
- Avoid “minor issues remain”, “known issue” and “edge case”. Each hides which journey is affected and who agreed.
- A workaround only a developer can perform is not a workaround.
- The person who accepts the risk is named by Product or the business. The fix target is named by Engineering. QA records both.
- An acceptance has an end. Without a review date a deferral becomes permanent by default.
Terms used here: Deferred risk, Release readiness, User acceptance testing (UAT).