The PMO Gate Before Sprint One
Northgate Insurance is three years into an agile transformation, with six Scrum teams delivering a claims-handling platform. The programme is regulated: auditors must be able to show who approved each decision rule and when it changed. The PMO will not release development funding until a 60-page business requirements document and a full traceability matrix are signed off. At the same time, the team's definition of ready asks for stories two sprints ahead, and refinement sessions keep producing questions rather than answers. In the last quarter 30% of stories were reopened after sprint review, and an audit found two rules in production that no one could trace to an approval. The BA has nine weeks before the first release and two compliance stakeholders who insist every field-level rule must be specified up front, because 'you cannot retrofit audit'. The delivery manager wants the BA to just get the BRD signed and move on.
1. How should the BA respond to the PMO demand, and what would you actually produce? Explain the reasoning behind each artefact you commit to.
Read the worked answer
Separate the control objective from the artefact. What the regulator and PMO need is traceability and evidence of approval; what they have asked for is the document that delivered it in a waterfall world. The Agile Manifesto values documentation while favouring working software, and the Agile Extension to BABOK frames documentation as just enough, just in time - so the question is which documents earn their cost.
Three commitments are defensible. First, a short scope and constraints document of roughly ten pages covering outcomes, regulatory constraints, glossary and out-of-scope. It genuinely helps the funding gate and will not be invalidated by sprint three. Second, replace the static traceability matrix with a living rule catalogue held in the same tool as the stories: each rule is a versioned record with owner, approval date, rationale, linked stories, linked tests. Traceability becomes a report generated from it rather than a spreadsheet maintained by hand. Third, agree with audit what evidence means: a versioned approval record plus an executed test for each production rule.
What to resist is field-level specification up front. Accepting that makes design decisions before the team has learned anything and will push the 30% reopen rate higher. Offer instead that field-level rules are elaborated per sprint with compliance present in refinement, and that the BA will show a working catalogue in two sprints.
2. What would you change in the next refinement session to cut the reopened-story rate?
Read the worked answer
First check the cause, because reopen has at least two shapes: work that comes back because a decision changed after review, and work that comes back because it was defective. The two rules with no traceable approval suggest the first.
If it is decision latency, the fix is not more detail in the story, it is surfacing decisions explicitly. Before the session, take the three stories nearest the top of the backlog and run example mapping against them using the rule catalogue as input: rules in one colour, examples in another, unanswered questions in a third. Every question gets a named decision owner and a needed-by date, written on the story, rather than being logged as an open point that refinement leaves behind. Write acceptance criteria as given/when/then derived from the catalogue examples, and deliberately include boundary and negative cases for the two problem rules.
Then change the definition of ready: every story referencing a regulatory rule must point to an approved catalogue record, and no question may remain without an owner and date. That is a decision-focused addition, not a documentation-focused one, and it directly attacks the reopen mechanism instead of hiding it.
3. How would you demonstrate within eight weeks that this approach is at least as safe as the old one?
Read the worked answer
Argue with evidence rather than philosophy, and choose measures that the auditor and PMO already care about. Useful indicators are: proportion of stories reopened after sprint review; median elapsed days from question raised to decision recorded; percentage of rules in production traceable to both an approval record and an executed test, with a target of 100%; time taken to assemble evidence for an auditor, which should fall from days to minutes; and the number of rule changes made after sprint review.
Run a side-by-side comparison on a sample of ten rules, showing for each one the approval chain, the test evidence and the change history under the new catalogue versus what the old matrix could show. Include any audit findings in the period. Present the reopen rate and decision latency trend to the PMO alongside the sample.
The reasoning to state plainly: safety in a regulated sense means demonstrable control, not document length. If traceability is complete, evidence is faster to produce and fewer decisions are remade, the new approach is the stronger control even though it produces fewer pages. If those numbers do not improve, the BA should accept that the lightweight approach has failed and say so.