Sprint Ceremonies
QA's Role in Every Ceremony
QA engineers who only participate in standups are missing 75% of the value they can add. Each sprint ceremony is an opportunity to prevent bugs, communicate risks, and demonstrate the impact of quality work.
Sprint Planning
Sprint planning is where the team decides what work to commit to for the sprint. This is one of the highest-leverage moments for QA.
What QA Contributes
- Ask clarifying questions about acceptance criteria: "What should happen if the user enters an emoji in the name field?" often reveals undefined behavior that would otherwise become a bug.
- Identify testing dependencies early: Test data needs, environment setup, third-party service access, test accounts.
- Flag stories that require disproportionate testing effort: A "2-point" story that needs testing across 3 browsers, 2 APIs, and 4 user roles is actually a 5-point effort.
- Suggest splitting large stories: "Can we split this into 'basic checkout' and 'checkout with coupons' so we can test and ship incrementally?"
- Advocate for test infrastructure stories: "We need a story for fixing the 8 flaky tests from last sprint" should be a legitimate backlog item.
Common Planning Mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Testing effort not included in estimates | QA becomes the bottleneck at sprint end | Include testing in every story estimate |
| Stories without acceptance criteria | QA guesses what to test, misses requirements | Require acceptance criteria before pulling into sprint |
| No QA capacity reserved for tech debt | Flaky tests and infrastructure rot accumulate | Reserve 10-20% of sprint capacity for QA improvements |
| QA not invited to planning | Testing surprises emerge mid-sprint | QA is a required attendee, not optional |
Daily Standup
Standup is for coordination, not status reports. Keep it concise and focused on what the team needs to know.
QA Standup Pattern
Yesterday:
"I completed testing on SHOP-456 (login redesign). Found two medium-severity bugs, both filed and assigned."
Today:
"I am testing SHOP-789 (cart optimization). Need the staging database refreshed before I can start integration tests."
Blockers:
"The payment sandbox has been returning 503 since yesterday. I have opened a ticket with the provider but cannot test checkout until it is resolved."
Standup Tips for QA
- Lead with impact, not activity: "Found 2 bugs in login" is more useful than "Ran 50 test cases."
- Be specific about blockers: Include what is blocked, why, and what is needed to unblock.
- Surface dependencies early: If you need a developer to deploy a fix before you can continue testing, say it now, not at 4 PM.
- Keep it under 2 minutes: Save detailed discussions for after standup.
Sprint Review / Demo
Sprint review is when the team demonstrates completed work to stakeholders. QA can and should participate.
How QA Adds Value in Sprint Review
Show quality outcomes, not just features:
"We shipped the login redesign with 98% test coverage, found and fixed 4 bugs during the sprint, and reduced page load time from 2.1s to 1.4s."
This is far more compelling than "we tested it."
Demonstrate testing in action:
- Show a test run with live browser automation
- Show a coverage report before and after
- Show a performance comparison (before/after LCP, FID metrics)
- Show the traceability from requirement to test to evidence
Highlight risk:
- "Email notifications are not fully tested yet because the mail service was down for 3 days. We recommend holding this feature until Sprint 24."
- Stakeholders appreciate transparency about what is not ready far more than discovering it in production.
Sprint Review Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| QA does not attend demo | Quality work is invisible | QA presents quality metrics for 2-3 minutes |
| Only happy path shown | Stakeholders think everything is perfect | Show a failed test and how it was resolved |
| No metrics, just "it was tested" | No evidence of quality | Show pass rates, coverage, and defect counts |
Sprint Retrospective
The retrospective is where the team reflects on what went well, what did not, and what to improve. Quality-focused questions ensure testing improves sprint over sprint.
Quality-Focused Retro Questions
- Escaped defects: Did any bugs escape to production this sprint? Why did our tests miss them?
- Flaky tests: Which tests were flaky this sprint? What is the plan to fix them?
- Bottlenecks: Did testing become the bottleneck at any point? How can we shift left?
- Infrastructure: Are our test environments reliable? What infrastructure improvements would help?
- Automation ratio: Is our test automation ratio improving or declining?
- Test creation velocity: Are we writing tests fast enough to keep up with feature development?
Turning Retro Items into Action
A retro insight without an action item is wasted. Every quality improvement should become a specific, assignable task:
| Retro Insight | Action Item | Owner | Sprint |
|---|---|---|---|
| "3 bugs escaped to production" | Add edge case tests for coupon validation | QA Team | Sprint 24 |
| "Pipeline took 35 min, devs stopped waiting" | Add 2 more test shards, cache Playwright browsers | QA + DevOps | Sprint 24 |
| "Payment sandbox was down for 3 days" | Set up a local mock for payment API | Developer | Sprint 24 |
| "6 flaky tests this sprint" | Dedicate 1 day to flaky test investigation | QA Team | Sprint 24 |
Ceremony Time Allocation
| Ceremony | Frequency | Duration | QA Preparation |
|---|---|---|---|
| Sprint Planning | Start of sprint | 2-4 hours | Review upcoming stories, identify dependencies |
| Daily Standup | Daily | 15 minutes | Prepare 30-second update, note blockers |
| Sprint Review | End of sprint | 1-2 hours | Prepare quality metrics, demo materials |
| Sprint Retrospective | End of sprint | 1-1.5 hours | Collect quality data, prepare improvement proposals |
| Backlog Refinement | Mid-sprint | 1-2 hours | Review future stories for testability |
Hands-On Exercise
- Prepare a sprint planning contribution: review 3 upcoming stories and identify testability concerns
- Write your standup update for tomorrow using the pattern above
- Create a 3-minute sprint review presentation showing quality metrics for your current sprint
- Propose 3 quality-focused retrospective questions specific to your team's recent challenges
- Turn one retro insight from your last retrospective into a concrete, assignable action item