4 exercises — writing constructive retro items, turning personal blame into systemic observations, facilitating safely, and proposing SMART action items.
0 / 4 completed
1 / 4
You're writing a "What Went Well" item for the retrospective board. Which entry is most useful to the team?
Option C is the ideal "What Went Well" entry because it:
Names a specific practice: pair programming sessions — not just "teamwork" Links it to a specific outcome: caught the authentication bug early Proposes making it systematic: "worth building into the process" — turns an observation into a potential improvement
Why vague entries fail: "Everything went well" — no actionable signal; the team can't repeat what they can't name "Good sprint" — means nothing without specifics "We finished all the stories" — describes the outcome, not the practice that enabled it
The purpose of "What Went Well" is not celebration — it's to identify specific practices and behaviours worth repeating or institutionalising. If the team can't name the specific thing that worked, they can't deliberately do it again next sprint.
Format that works: [Specific practice or event] → [Specific positive outcome] → [Optional: how to build on it]
2 / 4
You want to write a "Could Be Better" retro item about missed deadlines without blaming any individual. Which phrasing is most constructive?
Option C demonstrates how to raise problems constructively in retros:
Describes the pattern, not the person: "deployment delays in the last two sprints" — systemic observation, not individual blame Quantifies the impact: "missed our release window twice" — makes the cost of the problem clear Proposes concrete next steps: audit CI/CD configuration + create a runbook — specific, actionable, not just "fix it"
Why the others fail: A — Personal blame shuts down psychological safety; people stop being honest at retros when they fear being singled out B — "Some people don't know" is passive-aggressive blame; "some people" is obvious code for specific people D — "Communicate better" and "be more organised" are the most common useless retro items; they describe desired states, not root causes or solutions
Retro language rules: • Describe systems and processes, not people • Name specific events, not personalities • Propose concrete next steps (what exactly should we do?) • Use "we" not "you" or "they" • If you can't propose a next step, ask: "What would success look like?"
3 / 4
You're facilitating the retro. During the discussion phase, a developer says: "The problem is Maria's estimates are always wrong and it causes us to overcommit." How do you handle this?
Option C demonstrates expert retro facilitation: reframe from personal to systemic.
Reframe technique: "It sounds like we have a broader challenge with estimation accuracy" — takes the spotlight off Maria and puts it on the system that produces inaccurate estimates Invites root cause analysis: offers three concrete hypotheses (hidden dependencies, unclear requirements, larger-than-expected tasks) Stays curious, not defensive: "What specific factors made estimation difficult?" — opens inquiry
Why the others fail: A — "Defend your estimates" puts Maria in the dock; she will feel attacked, become defensive, and the discussion becomes adversarial B — "Everyone who estimates badly" still encodes blame in different words; and it doesn't solve the root cause D — Avoiding the topic lets it fester; the retro exists specifically to have these conversations safely
Facilitation reframe phrases: • "It sounds like the underlying issue is…" • "Let's zoom out — what would need to be true for this to happen systemically?" • "Can we explore that as a system problem rather than an individual one?" • "What factors outside any one person's control contributed to this?"
4 / 4
The retro has surfaced several problems. You want to propose a concrete action item. Which format is most effective?
Option C follows the SMART action item format that retros require to actually produce change:
Specific: PR review turnaround SLA, 24-hour target — not "improve communication" Measurable: 24 hours is a verifiable standard Assigned: Alex is the named owner — not "the team" or "everyone" Time-bound: by Friday — not "soon" or "next sprint" Reviewable: "revisit in the next retro" — closes the loop
Why unspecific action items fail: "Try to do better" — no owner, no deadline, no success criterion "Add to backlog" — the backlog is where good intentions go to die; retro actions need dedicated owners, not a backlog ticket that never gets prioritised "Be more proactive" — means nothing without a specific behaviour change
The critical test for an action item: If you can't answer "who does what by when and how will we know it happened?" — it's not an action item, it's a wish.