The end of a sprint has two ceremonies. Teams confuse them constantly — either conflating them into one meeting, or treating both as formalities to rush through before the next sprint begins.
That's a mistake. The Sprint Review and the Sprint Retrospective serve fundamentally different purposes, have different audiences, and produce different outputs. Get them right, and your team gets smarter every sprint.
Learning Objectives
By the end of this lesson you will be able to:
- Distinguish between the Sprint Review and the Sprint Retrospective
- Describe the audience and purpose of each ceremony
- Explain why the Retrospective is the most important meeting in Scrum for QA engineers
- Describe what a healthy Retrospective produces
Sprint Review: Showing What You Built
The Sprint Review is the ceremony where the Scrum team presents the Increment to stakeholders and collects feedback.
Purpose: Inspect the Increment and adapt the Product Backlog based on what was learned.
Audience: The Scrum team + stakeholders (Product Owner, business representatives, customers, anyone with a stake in the product).
What happens:
- The team demonstrates working software (not a slideshow, not a prototype — working software)
- Stakeholders ask questions and provide feedback
- The PO discusses what's been done vs. what's still outstanding
- The backlog is updated based on the feedback received
Time-box: Up to 4 hours for a 4-week sprint.
Key principle: The Sprint Review is NOT an acceptance meeting. Stakeholders are not there to "approve" or "reject" features. They're there to provide feedback that makes the next sprint more valuable.
QA in the Sprint Review
QA has a dual role in the Sprint Review:
Before the review: QA has already verified that the Increment meets the Definition of Done. Nothing gets demonstrated that QA hasn't signed off on. The Sprint Review is a showcase of verified, working software — not a "let's see if it works" session in front of stakeholders.
During the review: QA can contribute context: "We found 3 minor issues that were fixed during the sprint — here's what they were and how they were resolved." This transparency builds trust with stakeholders.
Sprint Retrospective: Improving How You Work
The Sprint Retrospective is the ceremony where the team reflects on its own processes and practices from the previous sprint, and creates a plan for improvement.
Purpose: Inspect how the sprint went with regards to people, relationships, process, and tools — and identify improvements.
Audience: The Scrum team ONLY. No stakeholders, no management (unless a manager is a member of the Scrum team). This is an internal team meeting.
What happens (classic format):
- What went well? — Practices and behaviors the team wants to continue
- What could be improved? — Friction points, inefficiencies, recurring problems
- Action items — Specific, owned, time-bound commitments to change something in the next sprint
Time-box: Up to 3 hours for a 4-week sprint.
The output: Not a document. Not a report to management. A short list of actionable commitments: "Starting next sprint, QA will join the developer walkthrough before testing begins" — with an owner and a definition of what "done" looks like for that improvement.
Why the Retrospective Is the Most Valuable Meeting for QA
QA engineers have a unique vantage point in a Scrum team. They see where the process breaks down — the stories that arrive for testing without acceptance criteria, the environments that are always broken, the regression areas that keep surprising everyone.
The Retrospective is the designated space to bring those observations — with data, not complaints:
- "We found 7 bugs in the payment flow this sprint. 5 of them were in edge cases not covered by acceptance criteria. Proposal: let's add edge case examples to the AC template."
- "QA was blocked for 1.5 days waiting for staging deployment. Proposal: let's agree that the developer deploys to staging and notifies QA before marking a story as 'ready for testing.'"
These are process improvements that make the next sprint better. That's the entire point.
The Difference, Summarized
| Sprint Review | Sprint Retrospective | |
|---|---|---|
| Focus | The product | The process |
| Audience | Team + stakeholders | Team only |
| Output | Updated Product Backlog | Action items for process improvement |
| Question answered | "What did we build?" | "How did we build it, and how do we build better?" |
Pro Tips
The fastest way to ruin a Retrospective: make it a blame session. When things go wrong, ask "what about our process allowed this to happen?" — not "who caused this?" The first question produces improvements. The second produces silence.
If every Retrospective produces the same problems, the action items aren't being followed through. Start the next Retro by reviewing last Retro's action items. If they weren't done, ask why — before adding new ones to the list.
A Sprint Review where no stakeholder asks any questions is a warning sign. Either the team is building exactly what was expected (rare), or stakeholders aren't engaged (common and dangerous).
Summary
- Sprint Review: Team shows working software to stakeholders; feedback informs the Product Backlog. External audience. Inspects the product.
- Sprint Retrospective: Team inspects its own process; produces specific action items. Internal audience (team only). Inspects the process.
- QA ensures nothing reaches the Sprint Review without passing the DoD; QA also brings data-driven process observations to the Retrospective.
- The Retrospective is the mechanism of continuous improvement in Scrum — teams that skip it stop improving.
- Good action items are specific, owned, and time-bound. "We should communicate better" is not an action item.