Requirements Traceability (Agile)

This is a traceability view for an Agile program — and it is deliberately not a waterfall requirements traceability matrix. On MedConnect Mobile, requirements are not a fixed document to be traced against; they are a living Product Backlog of epics and user stories, verified by a shared Definition of Done, delivered sprint by sprint. This view makes that chain explicit — Vision → Epic → Story → Definition of Done → Sprint/Release — and shows every one of the 33 stories tracing cleanly through it.

01 Why the backlog is the traceability vehicle

A waterfall RTM exists because requirements are captured once, up front, in a document that the delivered system is later checked against — the matrix guards against the system drifting from a frozen baseline. Agile has no frozen baseline. Requirements emerge and are re-prioritised every sprint, so a static matrix would be stale the day it was signed. Bolting one onto a Scrum program would not add rigor; it would signal a misunderstanding of how the program actually works.

What Agile has instead is traceability built into the flow of work. Every requirement is a user story with a unique ID; every story rolls up to exactly one epic; every epic serves the product vision; and every story is verified against one shared Definition of Done before it can be called complete. The trace is not a document maintained alongside the work — it is the work, and it is always current because the backlog is the single source of truth the teams pull from each sprint. This view simply makes that living structure legible in one place.

02 Vision → Epic → Story

Every epic traces up to the product vision and down to its user stories. The stories below are the complete backlog: each has a unique ID, a MoSCoW priority, a story-point estimate, and a target sprint, and each belongs to exactly one epic. There are no orphan stories and no empty epics — that closure is the first thing this view verifies.

03 Story → Definition of Done (the acceptance gate)

In a waterfall RTM, each requirement traces to its own verification method. In Agile, every story traces to the same gate — the Definition of Done — and that is a strength, not a gap. A single, shared, enforced definition means a completed story means the same thing regardless of which squad delivered it, which sprint it landed in, or how large it was. Uniform verification is what lets two squads (Falcon and Anchor) work in parallel and still produce one coherent product.

A story is not "done" when a developer says so; it is done when it satisfies every item of the DoD:

• Acceptance criteria (defined when the story was Ready) all met and demonstrated
• Code reviewed by at least one other engineer and merged
• Unit and integration tests written and passing
• No open defects above the agreed severity threshold
• Deployed and verified in the staging environment
• Documentation updated where the story changed behaviour

04 Story → Sprint → Release

The final link is delivery. Each story carries a target sprint, and sprints roll up into the two releases on the roadmap. This is where Agile traceability terminates — not in a one-time acceptance signature, but in a working increment demonstrated at the Sprint Review and, at release boundaries, shipped. Because the target sprint travels with the story in the backlog, the trace from a requirement to the increment that delivered it is always one lookup away, and it updates itself as re-planning moves stories between sprints.

05 What this view does and does not guarantee

Honesty about the limits of the trace is part of the discipline. What this view guarantees: every story has a unique ID, belongs to exactly one epic, carries a priority and estimate, has a target sprint, and is subject to the same Definition of Done. What it deliberately does not do:

• It does not freeze scope. The backlog is re-prioritised every sprint; this view is a snapshot of a living structure, not a baseline to hold the teams to. That is by design — a frozen Agile backlog is a contradiction.
• It does not trace per-story acceptance criteria line by line. Acceptance criteria live on each story in the backlog and are verified at story level against the DoD; enumerating them here would duplicate the backlog and go stale faster than it.
• It does not assign a separate verification method per requirement. In Agile that is a feature: the shared DoD is the verification method, uniformly, and dividing it per story would fragment the single quality bar that lets the squads stay coherent.