Agile Mortgage Delivery Versus Regulatory Traceability
You are a senior BA on a digital mortgage application at a retail bank moving from waterfall to agile. The product owner wants you to write user stories just-in-time for each sprint. However, the compliance department requires a full requirements traceability matrix (RTM) signed off before any development starts, citing a regulatory audit finding last year that identified three undocumented changes to mortgage calculations. The first sprint starts in four weeks. The delivery team has eight developers, two testers, a scrum master, and you. The compliance manager has rejected the last two attempts at 'agile documentation' as insufficient, saying the RTM must show explicit links from regulations to code. The product owner is frustrated and says compliance is blocking progress. The program manager wants you to 'sort it out' within two weeks.
1. How would you reconcile the agile approach with the compliance requirement, and what artefacts would you produce?
Read the worked answer
I would not treat this as a binary choice. First, I would clarify what compliance actually needs: an auditable trail from regulation to implemented code, with sign-off at an appropriate level. I would propose a lightweight but rigorous approach: an RTM at the epic level, not the user story level. Each epic would be linked to the relevant regulatory control, and each user story within the epic would inherit that link. I would create a 'regulatory definition of done' that includes evidence of traceability. I would also use a requirements information model to show how regulations, business rules, and user stories relate. For the first sprint, I would produce a sample RTM for one epic and walk compliance through it. I would agree on a cadence: compliance reviews the RTM at each sprint review, not before every sprint. This gives compliance the audit trail and the product owner the just-in-time flexibility. I would document this as a working agreement.
2. How would you engage the compliance manager and the product owner to move forward?
Read the worked answer
I would facilitate a joint workshop with the compliance manager, product owner, and perhaps internal audit. The goal is to move from 'agile vs compliance' to 'how do we meet both'. I would ask compliance to show the specific audit finding and explain what would satisfy it. I would ask the product owner to explain the risk of upfront detailed requirements (e.g., rework, delayed feedback). Then I would co-create the lightweight RTM approach. I would volunteer to produce a pilot artefact within one week to build trust. If the compliance manager remains rigid, I would escalate to the program manager with a risk assessment, but only after attempting collaboration. I would also keep the product owner informed and involved, so they don't feel sidelined. The key is transparency and demonstrating that compliance can be met without reverting to waterfall.
3. What would a minimum viable traceability approach look like in practice?
Read the worked answer
A minimum viable traceability approach would include: (1) a regulatory register listing each relevant regulation and its interpretation; (2) an epic map linking each epic to one or more regulations; (3) a definition of ready that requires each user story to reference its parent epic; (4) a definition of done that includes evidence of testing against the regulatory control; (5) a sprint review artefact showing the RTM updated. I would avoid a 500-line spreadsheet in favour of a tool like Jira with linked issues and a reporting dashboard. I would also agree with compliance on sampling: they audit a sample of epics each sprint rather than reviewing every story. This reduces overhead while maintaining assurance. I would pilot with the first sprint and refine based on feedback. The measure of success is that internal audit can follow the chain from regulation to code within minutes, not that every requirement has a 10-page specification.