A QMS built in a 12-month waterfall ends up as a stack of files — and a team that doesn't own it. We translate clauses into Epics, sub-processes into Features and individual requirements into User Stories. The result: a QMS in 2-week sprints — audit-ready and effective in daily operations.

Why classic QM rollouts fail

Traditional QM implementations follow a waterfall: gap analysis, concept, documentation, training, internal audit, certification. Concept to operations often takes 9 to 12 months. The result is often a manual nobody reads, a standard nobody recognises, and processes that quietly run in parallel to the ones actually lived.

The reason isn't lack of discipline — it's the architecture. Planning everything at once means testing fit too late. Working on 100 requirements simultaneously means losing prioritisation. Building a QMS "top-down" means building it without the people who carry it day to day.

The agile translation

Agile methods — from software, now widespread in engineering and product development — offer a clear alternative. Three terms matter:

Epic — a clause or QM headline topic

An Epic is the largest unit. It bundles everything that belongs to a topic. Examples from ISO 9001:2015:

  • Epic 4.1–4.4: Context of the organisation — internal and external issues, interested parties, scope.
  • Epic 5: Leadership — responsibility, quality policy, roles.
  • Epic 8: Operation — planning, requirements, development, procurement, production.

For FSSC 22000 v6 in the same logic: food safety management, HACCP, allergen management, quality culture, equipment management — each its own Epic.

Feature — a sub-process inside the Epic

Features break the Epic into sub-processes that together fulfil the larger goal. Example: Epic "Procurement and supplier management" (ISO 9001, 8.4):

  • Feature 1: Supplier evaluation and selection.
  • Feature 2: Supplier audit programme.
  • Feature 3: Incoming-goods inspection.
  • Feature 4: Supplier-performance monitoring.

Each Feature is a standalone process with an owner, an input, an output and a measurable effectiveness indicator.

User Story — the individual, testable requirement

User Stories phrase concrete requirements from the perspective of the role that has to implement them. Format: "As role I want action so that outcome." Examples for the supplier-evaluation Feature:

  • As a buyer, I want to evaluate new suppliers using a standardised questionnaire so that qualification is traceable.
  • As a quality manager, I want to audit critical suppliers annually on-site so that risks are detected early.
  • As production manager, I want to see the OTIF rate per supplier so that I can manage bottlenecks early.

Each story is concrete, testable and tied to a role. That's the smallest meaningful delivery unit of a QMS.

The Definition of Done — what "done" really means

Classical QM treats a requirement as fulfilled when it appears in the manual. Agile QM treats it as fulfilled when it is audit-ready. We use a concrete Definition of Done for every User Story:

  1. Process or procedure document created and stored in the DMS.
  2. Approved by a qualified reviewer (four-eyes principle).
  3. Responsible role named and assigned in the org chart.
  4. Clause reference documented (which ISO/FSSC requirement is met).
  5. Training delivered and recorded.
  6. At least one effectiveness record (log, KPI, report).

Any item open — the story stays in the sprint. That discipline is what separates a "paper-ready" QMS from an audit-ready one.

Sprint structure — how a QMS grows in two weeks

We work in 2-week sprints with a fixed structure:

  • Sprint Planning (Day 1, 2 h): Pick 6–10 User Stories from the backlog. Estimate capacity realistically.
  • Daily Stand-up (15 min): Progress, blockers, mutual help.
  • Review (Day 10, 90 min): Present stories, accept formally.
  • Retrospective (Day 10, 60 min): What worked, what must change.

After 6 sprints (12 weeks) you typically have an audit-ready MVQ — see the article on the Minimum Viable QMS.

What we pay particular attention to

The method only works under three conditions:

  • User Stories from the role's view, not the standard's view. "The organisation shall…" is standard language, not a user-story format. We write stories so the role sees what they personally do.
  • Vertical slices, not horizontal ones. A sprint delivers one complete Feature audit-ready, not "all documents half-done across all Features".
  • Ownership stays with the team. We facilitate, coach and safeguard method. But the stories are delivered by the team whose process is described.

Conclusion

Epics, Features and User Stories aren't just vocabulary from another industry. They structure a QMS so it grows in tangible increments — and so each sprint yields value beyond "more documentation". A system becomes audit-ready when it works in daily life. Audit-ready in sprints means: every other week a step closer to reality, not every quarter a new concept paper.

Lean-QA: audit-ready quality systems in sprints — not in filing cabinets.