CHAPTER 09
Beginner
Sprint Review and Retrospective
Updated: May 16, 2026
25 min read
# CHAPTER 9
Sprint Review and Retrospective
1. Introduction
The Sprint is over. The Developers have successfully built a new feature. In traditional environments, they would immediately grab the next ticket and start coding again. Agile rejects this endless treadmill. At the end of every single iteration, Scrum mandates a hard stop to inspect the results. This occurs through two distinct, critical ceremonies: the Sprint Review and the Sprint Retrospective. One looks *outward* at the product; the other looks *inward* at the team. If a team skips these meetings, they break the empirical loop of Inspection and Adaptation, guaranteeing that bad software and toxic team habits will fester. In this chapter, we will master the final two events of the Sprint lifecycle.2. Learning Objectives
By the end of this chapter, you will be able to:- Distinguish between the Sprint Review (The Product) and the Sprint Retrospective (The Process).
- Facilitate an effective Sprint Review with external stakeholders.
- Understand the definition of a "Done" Increment.
- Facilitate a Sprint Retrospective in a psychologically safe environment.
- Utilize common Retrospective templates (e.g., Start, Stop, Continue).
3. The Sprint Review (Inspecting the Product)
The Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.- Attendees: The Scrum Team and Key Stakeholders (Clients, Executives, Users).
- The Focus: The Product. What did we build?
- The Format: It is *not* a PowerPoint presentation. It is a live demonstration of working software. The Developers show the new features, the stakeholders play with the software, and they give immediate feedback.
- The Outcome: The feedback might alter the Product Backlog. (e.g., The client says, "I love the new button, but it needs to be blue." The Product Owner instantly adds a "Change button to blue" ticket to the top of the backlog).
4. The Definition of "Done"
You cannot show half-finished code in a Sprint Review. A feature is only shown if it meets the Definition of Done (DoD). The DoD is a formal checklist (e.g., "Code reviewed, Unit tests pass, Deployed to staging, QA verified"). If a feature is 99% coded but not tested, it is NOT Done, and it is NOT shown at the Review. It goes back to the Backlog.5. The Sprint Retrospective (Inspecting the Process)
While the Review is about the Product, the Retrospective is entirely about the Team. It is the final event of the Sprint.- Attendees: The Scrum Team ONLY. (No stakeholders, no managers. This ensures psychological safety).
- The Focus: The Process, the Tools, and the People. How did we work together?
- The Goal: Plan ways to increase quality and effectiveness. The team must identify at least one actionable improvement to implement in the very next Sprint.
6. Retrospective Templates
To prevent the meeting from turning into a boring complaint session, Scrum Masters use interactive frameworks.- Start, Stop, Continue:
- *Start:* "We should start writing automated tests."
- *Stop:* "We should stop interrupting each other on Slack during focus hours."
- *Continue:* "We should continue doing pair programming; it worked great this week."
- Mad, Sad, Glad: Focuses on emotional reactions to the Sprint.
- Sailboat: "What is the wind pushing our sails? What are the anchors holding us back?"
7. Diagrams/Visual Suggestions
*The End-of-Sprint Fork*
txt
8. Best Practices
- Actionable Takeaways: A Retrospective is worthless if it just results in complaining. The meeting must end with 1 or 2 concrete Action Items assigned to specific people. (e.g., Instead of "Our deployments are slow," the action item is "John will spend 2 hours next Sprint researching CI/CD pipelines.")
9. Common Mistakes
- The Blame Game: The Retrospective must be a safe space. The "Prime Directive" of Retrospectives states: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time." If a Retrospective turns into pointing fingers and assigning blame, the team's trust is permanently shattered.
10. Mini Project: Run a "Start, Stop, Continue"
Scenario: You just finished a Sprint where 3 critical bugs made it to production, and the daily standups took 30 minutes every day. Fill out the Retrospective board:- Start: Start requiring a secondary peer code review before merging to production.
- Stop: Stop discussing technical solutions during the Daily Standup; use the Parking Lot.
- Continue: Continue using our new Jira board; the visibility was excellent.
11. Practice Exercises
- 1. Clearly differentiate the core focus and the attendee list of the Sprint Review versus the Sprint Retrospective.
- 2. Explain the "Definition of Done." Why is it dangerous to present a feature that is "mostly finished" to stakeholders during a Sprint Review?
12. MCQs with Answers
Question 1
During which Scrum event does the team collaborate directly with external stakeholders, clients, and executives to demonstrate working software and gather feedback?
Question 2
To ensure a psychologically safe environment where developers can speak honestly about process failures and team friction, who should be EXCLUDED from the Sprint Retrospective?
13. Interview Questions
- Q: During a Sprint Review, a CEO gets angry because a specific feature was not built, even though it wasn't part of the Sprint Goal. As the Product Owner, how do you manage this stakeholder's expectations?
- Q: You are a new Scrum Master. The team tells you, "We don't do Retrospectives anymore because nothing ever changes." How do you fix this broken feedback loop?
- Q: Explain the "Prime Directive" of Agile Retrospectives. Why is it essential for building high-performing engineering teams?