This is a ready-to-use definition of done (DoD) for GxP user stories delivered through Agile and CI/CD. It is the documentation contract: when a story meets its tier’s DoD, the evidence is complete by construction, and an auditor can be pointed at it. Replace every <<FILL: ...>> placeholder, tune the items to your quality system, and reference it from your validation plan. A filled specimen follows. This is general educational content to adapt, not regulatory advice.
How to use
Assign each story a risk tier at backlog refinement (see the tiering table). A story is not releasable until every item in its tier is satisfied. Do not apply the high-GxP DoD to a cosmetic story (it kills velocity and buy-in) or the low-GxP DoD to a story that touches a calculation, an audit trail, an e-signature, or a release decision (it kills compliance). The tier drives the rigor, exactly as Computer Software Assurance intends.
Risk tiering (assign before the story is built)
| Tier | Trigger | Test approach |
|---|---|---|
| High GxP | Changes a GxP calculation, an OOS/spec rule, audit trail content, e-signature meaning, or batch/release logic | Scripted acceptance test + automated regression + QA review of evidence; full traceability |
| Medium GxP | Adds a GxP report field or changes a workflow step with downstream review | Scripted or rigorous unscripted test + automated test; QA review of result |
| Low / non-GxP | UI layout, non-GxP filter, internal logging | Automated test + peer code review |
Section A: every story (all tiers)
| # | Item | Done? |
|---|---|---|
| A1 | Story statement is clear (role, capability, benefit) | <<FILL: Y/N>> |
| A2 | GxP classification and risk tier recorded | <<FILL>> |
| A3 | Acceptance criteria written, testable, and approved before build | <<FILL>> |
| A4 | Code peer-reviewed | <<FILL>> |
| A5 | Automated unit and integration tests written and passing | <<FILL>> |
| A6 | Regression suite passing on the build | <<FILL>> |
| A7 | Configuration/design change documented (or linked) | <<FILL>> |
| A8 | Test results retained as records (result, timestamp, version under test, environment) | <<FILL>> |
Section B: Medium and High GxP (add to Section A)
| # | Item | Done? |
|---|---|---|
| B1 | Traceability complete: requirement to test to result | <<FILL>> |
| B2 | Tests ran in a qualified or representative environment; the environment is identified | <<FILL>> |
| B3 | Change control reference linked | <<FILL>> |
| B4 | QA review of the result recorded | <<FILL>> |
Section C: High GxP only (add to Sections A and B)
| # | Item | Done? |
|---|---|---|
| C1 | Scripted acceptance test executed and evidence retained | <<FILL>> |
| C2 | SME witnessed or reviewed the high-risk acceptance evidence | <<FILL>> |
| C3 | Audit trail / e-signature behavior in regression scope and verified | <<FILL>> |
| C4 | QA release approval recorded for the increment to production | <<FILL>> |
| C5 | Release notes updated | <<FILL>> |
Acceptance criterion for the DoD itself
A new reviewer can pick any released GxP story and reconstruct the full thread (requirement, risk, design, test, result, approval) from the retained evidence, without interviewing the developer. If the knowledge lives only in a chat thread or someone’s head, the DoD is not met.
References
FDA Computer Software Assurance for Production and Quality Management System Software (current version issued 3 February 2026), for risk-based and automated evidence. ISPE GAMP 5 (2nd ed.), iterative development and software tools (referenced by title; described in original wording). 21 CFR Part 11 and EU GMP Annex 11, for records, audit trail, and controlled change.
Sign-off (High GxP)
| Role | Name | Signature | Date |
|---|---|---|---|
| Product owner / SME | <<FILL>> | ||
| Validation lead | <<FILL>> | ||
| QA (release approval) | <<FILL>> |
Filled specimen
The following shows the DoD completed for a High GxP story, so you can see how the evidence hangs together. Illustrative.
Story: US-1042, “As a QC analyst, I want the LIMS to flag an out-of-specification result so it cannot be silently released.” Tier: High GxP (data integrity + batch disposition). Built in v2.7.0.
| # | Item | Done | Evidence |
|---|---|---|---|
| A2 | GxP classification and tier | Y | High GxP, recorded at refinement 2026-03-04 |
| A3 | Acceptance criteria approved before build | Y | Given/When/Then, product owner accepted 2026-03-04 |
| A6 | Regression passing | Y | CI run 8842, all green |
| A8 | Test results retained | Y | CI run 8842: result, timestamp, v2.7.0, env QA-2 |
| B1 | Traceability complete | Y | URS-07 to AT-1042-01 to CI test OOS-flag-001 |
| B2 | Qualified/representative env | Y | Env QA-2, config baseline CFG-1042 |
| C1 | Scripted acceptance executed | Y | AT-1042-01, evidence retained, PASS |
| C3 | Audit trail in regression, verified | Y | Audit entry captured with user/timestamp/reason |
| C4 | QA release approval | Y | QA approved release 2026-03-07 |
The complete thread reads: requirement URS-07, risk High GxP, acceptance criteria approved before build, an automated test (OOS-flag-001) and a scripted test (AT-1042-01) both retained with the version under test, audit-trail behavior verified in regression scope, and a recorded QA release approval. When an auditor asks how this change was validated, this row set is the answer, no interview required.
Common inspection findings this checklist prevents
- A definition of done that exists on paper but is bypassed under schedule pressure.
- Acceptance criteria written after the demo to match what was built.
- Test results not retained for the version actually released.
- Audit trail or e-signature behavior left out of the regression scope, so a routine change breaks it undetected.
- Every story getting the same treatment, so velocity or compliance is sacrificed wholesale.
How to adapt this checklist
- Set your tiering triggers in the table to match the GxP functions your system actually holds.
- Wire the Section A items into your pipeline gates so a story cannot be marked done without them.
- Keep the High GxP sign-off explicit; the QA release approval is the authorization for the validated-state change.
- Reference this DoD from the Agile validation plan so the standard is a controlled document, not a team habit.
- Confirm the CSA version and predicate-rule references against the current source before issue.