Look-back
Release Cadence Audit
If every version is assessed in isolation, the same hole in the freeze packet can survive for a year.
A cadence audit is a look-back, not a review of a candidate build. We ask which artefacts keep arriving late, which findings keep being marked “known” and then forgotten, and whether support is told about limitations before users are.
This sits well after two or three painful launches, or after a team has grown and the original freeze checklist no longer matches who actually does the work.
The output is deliberately short on slogans. You get a revised evidence list and a record of where the last versions disagreed with themselves.
Who it is for
Teams that ship often and keep rediscovering the same launch-week surprises.
What you leave with
A cadence report: repeating gaps, where they enter the freeze packet, and a revised evidence list for the next three versions.
Preparation
Pick versions that actually shipped. Include at least one version that hurt support, even if it is uncomfortable.
Constraints
We need honest launch-week notes. Sanitised packets produce a polite report that will not help the next freeze.
Included
- Review of three to five completed release packets
- Interviews with release, support, and (where they exist) store-listing owners
- A written cadence report and a one-page evidence list for the next freeze
Not included
- Re-opening old incidents for blame
- Re-testing historical builds
- A programme of coaching sessions
How this assessment is delivered
Packet collection
You gather notes, crash extracts, and launch-week support logs for the agreed versions. Missing packets are recorded as a finding, not padded.
Pattern read
We look for the same omitted artefact: halt owners, language coverage, store questionnaire drift, soak time that exists only on a calendar.
Next-freeze list
You leave with a short list of evidence the next version must include, not a catalogue of process slogans.