5.2 Sprint Retrospective

5.2 Sprint Retrospective

Scrum Guide 2020: The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. The inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

PSPO I candidates sometimes skim the Retrospective because it “feels like a team process meeting.” That is a mistake. Product Owners who skip it, dominate it as bosses, or treat it as optional theater miss questions on continuous improvement, Definition of Done evolution, and the Product Owner’s place inside the Scrum Team.

---

Purpose: Increase Quality and Effectiveness

The Retrospective is not a complaint session, a blame tribunal, or a social hour. Its purpose is to plan ways to increase quality and effectiveness.

Improvements can be technical, collaborative, or product-management related. Anything that improves how the Scrum Team works within Scrum is in scope—including how the Product Owner manages the backlog, collaborates in refinement, and engages stakeholders.

---

What Is Inspected

The Guide lists specific inspection dimensions for how the last Sprint went:

1. Individuals

Skills, availability, clarity of accountabilities, and whether people had what they needed to contribute. This is not a performance review owned by the Product Owner. It is team-level inspection of conditions that help or hinder effectiveness.

2. Interactions

How people collaborated: PO–Developer clarification loops, Daily Scrum usefulness, stakeholder handoffs, conflict handling, and respect for self-management. Many “product problems” are interaction problems (late answers on PBIs, side-channel priorities, unclear Sprint Goal ownership).

3. Processes

How the team runs Scrum events, refinement, integration, release practices, and decision paths. Process inspection asks whether the team’s way of working supports empiricism—or creates waste and fake certainty.

4. Tools

Build pipelines, backlog tools, analytics, design systems, environments—anything that speeds or slows a usable Increment. Tools serve the team’s ability to inspect and adapt; they are not the product goal themselves.

5. Definition of Done

The team inspects whether DoD still creates transparent, quality Increments. DoD may improve over time as the team’s practices mature. Weakening DoD under pressure is not continuous improvement; strengthening quality standards that make Increments more trustworthy is.

Domain variation: The Guide notes inspected elements often vary with the domain of work. A medical device team and a marketing campaign team inspect different tools and process details—but the five categories remain the frame.

Assumptions that led them astray

The Guide adds that assumptions that led the team astray are identified and their origins explored. This is pure empiricism: wrong forecasts, misunderstood stakeholder needs, underestimated dependencies, or optimistic “we can skip testing” beliefs are learning material—not secrets to hide.

The team also discusses:

• What went well
• What problems it encountered
• How those problems were (or were not) solved

Balanced inspection prevents pure negativity and pure happy-path denial.

---

From Insight to Action: Most Impactful Improvements ASAP

Talk is not enough. The Scrum Team:

1. Identifies the most helpful changes to improve effectiveness
2. Addresses the most impactful improvements as soon as possible
3. May add those improvements to the Sprint Backlog for the next Sprint

Exam line: The most impactful improvements are addressed ASAP and may even be added to the Sprint Backlog for the next Sprint. That makes improvement real work—not optional after-hours charity.

Who decides how improvement work is planned inside the next Sprint? Developers own the Sprint plan for how work gets done; the Product Owner collaborates on value trade-offs if improvement work competes with product features. Continuous improvement is a team commitment, not a tax the PO unilaterally forbids or a secret Developers pursue without transparency.

---

Concludes the Sprint; Timebox

Order of the late Sprint events

1. … Sprint work / Daily Scrums …
2. Sprint Review (second to last)
3. Sprint Retrospective (last — concludes the Sprint)
4. Next Sprint begins with Sprint Planning (new Sprint)

Common trap: Swapping Review and Retrospective order, or claiming Planning ends the Sprint. The Retrospective is the closing event of the current Sprint.

---

Who Participates: The Whole Scrum Team

The Sprint Retrospective is for the Scrum Team: Product Owner, Scrum Master, and Developers.

Product Owner is not a guest or a boss

Wrong PO stances:

• Skipping the Retrospective because “process is the Scrum Master’s job”
• Attending only to receive a status summary
• Using the event to evaluate individual Developers’ performance for HR
• Dictating improvement actions without team ownership
• Defending every backlog complaint without openness

Right PO stance:

• Participate as a team member with Openness, Respect, and Courage
• Own feedback about backlog clarity, availability, ordering surprises, and stakeholder chaos the PO can influence
• Partner on improvements that increase product value delivery—not only technical craft
• Protect psychological safety by modeling non-blame inspection of shared system problems

Stakeholders are not default Retrospective attendees. The event is for the Scrum Team’s internal improvement. Bringing managers in as judges destroys openness. (If organizational coaching is needed, that is often Scrum Master work with the organization—not converting Retro into a public status autopsy.)

---

Product Owner Angle: Collaboration, Refinement, Stakeholder Interaction Quality

PSPO I especially cares about improvements in the product management system, not only code quality.

Improve collaboration

Examples of PO-relevant Retrospective topics:

• Were Product Backlog items clear enough at Sprint Planning?
• Was the Product Owner available for clarification during the Sprint?
• Did mid-Sprint stakeholder pressure bypass the Product Owner?
• Was the Sprint Goal used as a focus tool or ignored for a shopping list of PBIs?

Improvements might include better clarification SLAs, joint refinement habits, or SM coaching for stakeholder bypasses.

Improve refinement

If the team repeatedly pulls unclear items, the Retrospective should surface that system failure. Improvements may include:

• A light refinement cadence that keeps the top of the backlog ready
• Pairing Developers with the PO on acceptance intent earlier
• Splitting large items before Sprint Planning
• Making Product Goal linkage explicit on top items

The Product Owner remains accountable for effective Product Backlog management; the Retrospective is where the team plans how to get better at supporting that accountability together.

Improve stakeholder interaction quality

Stakeholder collaboration often fails in recognizable ways:

The Retrospective can plan how the Scrum Team will change its interaction design with stakeholders—while the Product Owner continues to own value decisions.

Definition of Done and quality (PO interest)

Product Owners benefit when DoD is strong: Increments are transparent and releasable. In the Retrospective, the team may decide to improve DoD (for example, add automated checks that prevent false “Done”). The PO should support quality improvements that protect empiricism and resist pressure to ship undone work for demo optics.

---

Relationship to Other Events

Do not merge Review and Retro into one meeting that only demos features and never improves the system. Both are mandatory Scrum events with distinct purposes.

---

Common PSPO I Traps on the Retrospective

---

PSPO Scenario Drill

Scenario: Every Sprint Review, stakeholders are surprised by what was built. Developers say PBIs were vague. The Product Owner says “we don’t have time for refinement.” Retrospectives list the same issue for three months with no change. Leadership asks why “Scrum isn’t working.”

Sound team response in the next Retrospective:

1. Inspect interactions and processes: late clarification, no refinement, surprise at Review.
2. Identify a most impactful improvement—for example, a weekly refinement session co-owned in practice by PO + Developers, with top-of-backlog readiness criteria.
3. Put concrete improvement work into the next Sprint Backlog if it needs capacity (facilitation setup, splitting large items, clarifying Product Goal linkage).
4. Inspect whether Definition of Done and Sprint Goal practices also contributed to false forecasts.
5. Scrum Master coaches effectiveness; Product Owner accepts accountability for backlog clarity improvements without blaming Developers for guessing intent.

That scenario links Retrospective purpose, inspection dimensions, ASAP improvements, Sprint Backlog follow-through, and the Product Owner as team member—exactly the model PSPO I tests.

---

Quick Self-Check

You should be able to state without notes:

• Purpose: plan ways to increase quality and effectiveness
• Inspect: individuals, interactions, processes, tools, Definition of Done (+ assumptions, what went well/problems)
• Act: most impactful improvements ASAP; may enter next Sprint Backlog
• Timing: concludes the Sprint; max 3 hours for one-month Sprint
• Who: whole Scrum Team; PO participates as team member to improve collaboration, refinement, and stakeholder interaction quality