The most common complaint about QA in agile teams: "QA slows us down." When I hear this, my first question is always: where in the sprint does QA happen? The answer is almost always the same. QA happens at the end. Development finishes on day 12. QA runs on day 13-14. Release is on day 15. And anything QA finds on day 13 creates a choice between delaying the release and shipping with known bugs.
That is not QA slowing you down. That is QA scheduled in a position where it cannot do anything useful without creating a problem. The fix is not faster QA. It is earlier QA.
Sprint Planning: The Most Valuable QA Activity Most Teams Skip
Sprint planning without a QA engineer present is an opportunity cost that is almost never recognized as such. The stories are written, the acceptance criteria are defined, the estimates are set, and development starts – all without anyone asking the question that would prevent the most expensive kind of defect: "How do we know when this feature is working correctly?"
When a QA engineer participates in sprint planning, three things happen that would not happen otherwise:
Acceptance criteria get tested: Writing test cases before implementation starts is a forcing function for clear acceptance criteria. If you cannot write a test case for an acceptance criterion, the criterion is ambiguous. Finding that ambiguity in planning costs 10 minutes. Finding it after implementation costs a full sprint.
Edge cases surface early: QA engineers think in edge cases. When a developer writes a story about a file upload feature, they are thinking about the happy path. The QA engineer is thinking about what happens when the file is too large, when the file type is not supported, when the upload times out halfway, and when the user uploads the same file twice. These questions in planning prevent bugs in production.
Definition of done is specific: A story with test cases in sprint planning has a clear, testable definition of done. There is no ambiguity about whether the feature is "done" – it is done when the test cases pass. This reduces the "is this done enough to release?" uncertainty at the end of the sprint.
The best investment in agile QA is not more testing at the end of the sprint. It is a QA engineer in sprint planning, writing test cases before development starts. This one change consistently produces the largest reduction in escaped defects in our client engagements.
During the Sprint: Testing as Features Become Testable
The second shift that makes QA work in agile: start testing as soon as a feature is testable, not when the sprint ends. A two-week sprint does not mean QA waits two weeks to start. It means QA runs continuously as work becomes available.
In practice, this means a developer signals when a feature is ready for testing – usually by moving the story to a "Ready for QA" column or notifying in Slack. The QA engineer picks it up within 24 hours. Defects found in the middle of the sprint are fixed while the developer is still in context on that code. Defects found on day 13 require the developer to context-switch back into code they mentally closed two days ago.
This requires that the testing environment stays stable during the sprint. If the staging environment is being continuously deployed to, features being tested may break mid-test because an unrelated change was deployed. For teams with frequent deployments, a dedicated QA environment that only receives changes when features are ready for testing is worth the infrastructure overhead.
Sprint Review: What QA Should Demonstrate
Sprint reviews show completed work. The QA perspective on "completed" is specific: a feature is not complete until it passes the test cases that were written in sprint planning. This should be visible in the sprint review – not as a separate QA report, but as a natural part of demonstrating the feature.
When a developer demonstrates a feature in the sprint review, they show the happy path. The QA engineer can add context: "We also tested the cases where X and Y happen, and here is what the behavior looks like." This is not a QA status report – it is shared ownership of the feature's completeness.
Features that did not pass their test cases do not get demonstrated as complete in the sprint review. They go back into the backlog as bugs, with the associated test cases marking exactly what needs to be fixed. This maintains the integrity of "done" as a meaningful term.
Retrospective: Using Quality Data to Improve the Process
QA brings data to retrospectives that most teams don't have without an embedded QA function: escaped defects from the previous sprint, coverage metrics, test execution results, and areas where the test cases were insufficient to catch the bugs that escaped.
An escaped defect retrospective is not about blame. It is about understanding why the process did not catch a specific bug and what change to the process would catch it in future sprints. The categories we typically analyze:
Was the defect in scope? If a bug escaped but was never in the test scope for that sprint, the question is whether the scope definition needs to change. If the payment flow changed but QA's scope only covered the new feature, not the regression to the payment flow, that is a scope definition problem.
Was the defect in scope but not caught? If a defect was within the test scope and the test cases existed but the bug was not found, the question is whether the test case was designed to catch it. A test case that verifies happy-path behavior will not catch an edge case bug even if both are in scope.
Was the defect not in scope for good reasons? Some bugs are not worth testing before they ship – the probability is low, the impact is low, and the testing cost is high. If a low-probability, low-impact bug escaped, that might be acceptable. The decision should be explicit, not accidental.
Want QA embedded in your sprint cycle?
We join your Jira, your Slack, and your sprint ceremonies from week one. A 30-minute call is enough to scope an engagement.
Book a Free CallThe Velocity Concern (and Why It Is Usually Wrong)
Teams worry that adding QA to sprint planning and requiring sign-off before "done" will slow velocity. In the first sprint, it often does. The sprint planning takes 30 more minutes. Stories that get QA sign-off take an extra day. Velocity numbers look lower.
By sprint three or four, velocity stabilizes – usually at a level equal to or higher than before. The reason: features that are done are actually done. Less rework from production bugs. Fewer sprint carry-overs because "done" features need additional work. Less developer time spent on hotfixes. The time spent on QA in the sprint is recouped in the time not spent fixing production bugs.
The teams that report the best long-term velocity numbers are the ones with the most rigorous sprint-embedded QA processes. That is not a coincidence.