HKSM

A short, end-of-Sprint meeting where the Scrum Team inspects how they worked and agrees on a few concrete improvements for the next Sprint.

Purpose & When to Use

Retrospect Sprint is held at the end of every Sprint, after the Sprint Review and before the next Sprint Planning. Its purpose is to examine team practices, tools, communication, and workflow, then decide on specific improvements to boost effectiveness in the next Sprint. It focuses on the process and teamwork, not on judging individuals.

Use it at the end of each Sprint and, when necessary, run a brief mid‑Sprint check‑in if an urgent pattern is harming progress. Capture lessons learned, refine team working agreements, and update items like the Definition of Done or Definition of Ready when needed.

Mini Flow (How It’s Done)

• 1) Set the stage: Scrum Master confirms timebox, attendees (Product Owner, Developers, Scrum Master), and a psychologically safe environment. Revisit working agreements and the goal of continuous improvement.
• 2) Review goals and past actions: Reconfirm the Sprint Goal and quickly inspect completion of improvement actions from the previous retro.
• 3) Gather data: Collect facts and observations: what went smoothly, where friction occurred, metrics or signals (e.g., carried-over work, blocked items, defects found, handoff delays), and feedback from the Sprint Review.
• 4) Generate insights: Group themes, look for root causes (e.g., 5 Whys), and identify patterns about process, tools, workflow, and collaboration.
• 5) Decide what to do: Select the top 1–3 improvements with the highest expected impact. Make them specific, testable, and time-bound, assign an owner, and agree how success will be measured.
• 6) Close and follow through: Update team working agreements and, if relevant, Definition of Done/Ready. Add improvement work to the next Sprint (as backlog items or explicit tasks). Record lessons learned and update the Impediment Log for issues beyond the team’s control.

Quality & Acceptance Checklist

• All Scrum roles attend and contribute; psychological safety is protected.
• Timebox respected; discussion is focused on learning and improvement, not blame.
• Prior retro actions are reviewed for status and outcomes.
• 1–3 SMART improvement actions are agreed, each with an owner and target date.
• Actions are made visible (backlog items or tasks) so they are planned and tracked next Sprint.
• Updates to working agreements, Definition of Done/Ready, and information radiators are captured.
• Important impediments are logged with escalation paths identified.
• Lessons learned are stored in a shared repository for future reference.

Common Mistakes & Exam Traps

• Mixing events: Confusing Sprint Review (product feedback with stakeholders) with Retrospective (team process). The retrospective is for the Scrum Team only.
• Too many actions: Creating a long wish list with no follow‑through. Exams expect a small number of high‑impact, owned actions.
• Skipping due to deadlines: Omitting the retro under pressure. Continuous improvement reduces future pressure.
• No data: Relying only on opinions; bring facts such as blocked items, carryover, defect trends, or cycle times.
• Blame culture: Targeting individuals instead of systems and workflows. The Scrum Master safeguards psychological safety.
• Not integrating improvements: Failing to place actions into the next Sprint’s work leads to no real change.
• Ignoring definitions: Forgetting to update Definition of Done/Ready and working agreements when changes are agreed.
• Wrong attendees: Inviting external stakeholders. The retrospective is a Scrum Team event; outsiders can inhibit open discussion.

PMP/SCRUM Example Question

During a Retrospect Sprint, the team identifies slow handoffs between development and testing as the main cause of carryover work. What is the best next step?

1. Create a high-level roadmap for the next release so leadership sees the bigger picture.
2. Add a SMART improvement to the next Sprint, such as pairing a developer and tester per story and updating the Definition of Done to include joint verification.
3. Ask stakeholders to attend the next retrospective to gather broader opinions.
4. Record the issue as a risk and proceed without changes until the release is complete.

Correct answer: B. The retrospective should yield specific, owned actions that change how the team works next Sprint; formalizing joint verification in the Definition of Done and pairing addresses the root cause and is trackable.