Quality Starts Before the Sprint
AQA activities do not begin when a developer picks up a ticket. They begin with the first discussions about the business need — the moment a problem is articulated and a solution starts taking shape.
The earlier quality thinking is introduced, the cheaper it is to course-correct.
Good Acceptance Criteria = Good Question Asker
The single most important quality activity before a sprint begins is asking the right questions. Every hidden assumption in a user story is a potential defect waiting to be discovered in production.
The QA’s role in this phase is not to write tests — it is to ask questions that reveal what the team does not yet know. This requires understanding:
- Why — what is the purpose of this story?
- Who — which user, which system, which context?
- How — what are the failure modes, the edge cases, the non-functional implications?
Only once why, who, and how are clear does the “what” become meaningful.
Power of N — Refinement
Power of 3 (also called Power of N) is the evolution of the Three Amigos grooming session. It brings together the Product Owner, QA, and Developer (and optionally UX or business stakeholders) to:
- Identify the business rules behind a story
- Specify concrete examples of expected behaviour
- Translate those examples into Gherkin scenarios (Given / When / Then)
- Assess risk and define appropriate test strategies (Risk Storming)
Each role contributes differently:
| Role | Contribution |
|---|---|
| Product Owner | Business purpose, user value, priorities |
| QA | All possible scenarios, failure paths, edge cases |
| Developer | Technical implications, implementation constraints |
| UX | Design compliance, user experience requirements |
A pre-refinement between PO and QA — before the full team session — is a highly effective practice. It allows the QA to arrive to refinement with clear scenarios rather than discovering ambiguity in front of the whole team.
Sprint Timeline
The sprint lifecycle in an AQA model has a clear structure:
Before the sprint
- PO and QA write user stories with Gherkin acceptance criteria
- Three Amigos / Power of N refines and validates them
- Stories meet the Definition of Ready before sprint planning
- PO and TL commit stories to the sprint
During the sprint
- Dev team builds the feature including unit and integration tests
- Dev team writes all automated functional and performance test steps
- QA validates that the DoR is met and quality gates are passing
End of sprint
- Team delivers user stories
- QA executes regression and validates the Definition of Done
The Sprint as a Quality System
The sprint is not just a delivery mechanism — it is a quality system. Every ceremony (refinement, planning, review, retrospective) is an opportunity to embed quality thinking. Every artifact (acceptance criteria, test cases, CI/CD pipeline) is a quality gate.
When quality is treated as a system property rather than a phase, the team stops asking “is it ready to test?” and starts asking “is it ready to ship?”