The 90-Minute Review That Found Two Real Defects
Meridian Pay is preparing release 4.2 of its merchant settlement platform. The business analyst circulated a 68-page requirements specification for the reconciliation module to seven reviewers (two BAs, three developers, two testers) at 08:50 for a 09:00 review meeting. No review type, checklist, or entry criteria were agreed; the invitation said only 'review meeting - please attend'. The meeting ran 90 minutes and produced 140 comments logged in a spreadsheet: 112 concerned wording, fonts, and section numbering; 26 were questions already answered elsewhere in the document; 2 concerned a genuine gap in how partial refunds are reconciled, and both had been raised by the same developer in the first ten minutes. One reviewer spoke for roughly half the meeting while the two testers said nothing. The BA defended each comment before the group discussed it. The same group must now review a 40-page interface specification for the card-scheme connection, and the delivery manager has asked you to 'cut the meetings down and get more useful comments out of them'.
1. Using the evidence in the setup, diagnose what actually happened: which review type was practised, which roles were missing or ineffective, and the three biggest causes of the poor yield.
Read the worked answer
What was practised. This was an author-led walkthrough wearing the label of a review. The symptoms are diagnostic: ten minutes of preparation for 68 pages, no defined objective, no checklist, and the author answering and defending each comment as it was raised.
Roles that were absent or ineffective.
- No moderator. Nobody controlled the flow, so the meeting drifted into style and wording. A moderator also protects the author from having to defend every point.
- No recorder with a defined scheme. Comments went into a free-text spreadsheet, so there is no way to classify them by defect type or severity afterwards.
- Author in defensive mode. Answering each comment before the group has agreed whether it is a defect suppresses the two testers and burns time.
- Seven people is too many for a discussion. Large groups produce dominance (here, roughly half the talking time from one person) and free-riding.
The three biggest causes of the poor yield.
- No preparation time. Reviewing 68 pages at meeting speed is structural, not attitudinal - most reviewers were reading the document for the first time while it was being discussed. Preparation is where most defects are actually found.
- No defined objective or checklist. With nothing to look for, attention defaults to what is easy to see: fonts, numbering, wording. That accounts for 112 of 140 comments.
- No entry criteria. A document with unresolved cross-references and duplicated answers was allowed into review, generating 26 questions that should have been resolved by the author's self-check.
The yield confirms the diagnosis: 2 substantive defects out of 140 comments (about 1.4%), and both surfaced in the first ten minutes - before the process had time to bury them.
2. Design the review of the 40-page interface specification. State the review type, roles, entry criteria, preparation logistics with time budgets justified by document size, meeting format, and exit criteria.
Read the worked answer
Review type. A technical review, not an inspection. The document is interface-focused, the team is under delivery pressure, and a full formal inspection with re-inspection would cost more than the risk justifies. Keep the option of escalating to inspection if the defect density turns out to be high.
Roles (5 people maximum). Moderator (you), author (present, answers questions only when asked, does not defend), recorder, and three reviewers: one developer, one tester, one integration/operations engineer. Drop the second BA and the third developer - they add attendance, not coverage.
Entry criteria. Version-tagged and frozen document; numbered sections; author self-check completed and recorded; all cross-references resolved; traceability to the upstream requirements list; checklist distributed; two working days' notice; access to the defect tracker for logging during preparation.
Preparation. Budget 90 minutes per reviewer for 40 pages, roughly one page every two minutes. That rate is deliberately slow because preparation is where the yield comes from - compare it with the 90 minutes the whole group previously spent on 68 pages. Reviewers log each defect directly in the tracker with location, description, type, and severity, rather than prose in an email.
Meeting. 60 minutes, moderator-led. Only items needing group clarification are discussed. No solution debates longer than two minutes; park them. The author answers questions but does not defend. The recorder confirms each logged item and its agreed classification.
Exit criteria. Every section covered; no open major defects; decision recorded explicitly as accepted, accepted with changes, or re-review required; metrics captured (preparation time, defects per page, defect type distribution, percentage of substantive defects).
3. The delivery manager wants 'fewer meetings and more useful comments'. Draft your response, including which of the two goals you would push back on and the evidence you would use.
Read the worked answer
Push back on 'fewer meetings', not on 'more useful comments'. The evidence says the meeting was not the bottleneck - the missing preparation was.
The evidence. Ninety minutes for 68 pages works out at roughly 0.75 pages per minute, which is reading speed, not reviewing speed. Of 140 comments, 112 were formatting and only 2 were substantive. One person spoke for about half the session. The meeting was therefore doing the work that preparation should have done, badly and once, with seven people watching.
What I would propose instead. Keep one meeting, but make it shorter (60 minutes) and smaller (5 people), and move the effort into preparation (90 minutes per reviewer). That is more total person-hours, not fewer - so I would be honest about the trade: we are buying defect yield with preparation time, and we should expect the meeting count to stay flat while the meeting length falls.
The risk in the manager's framing. 'Fewer meetings' applied to review usually means email-based commenting, which loses the interchange that catches cross-section inconsistencies - exactly the kind of gap that was found here in the partial-refund logic.
How I would settle it with data. Run the redesigned review on the 40-page specification and report back on three measures: substantive comments as a percentage of total comments (baseline 1.4%), defects per page, and reviewer-hours per accepted defect. If the new format does not beat the baseline on those, the manager has a fair case for cutting review effort and I would adjust.