Scrum Checklist Retrospective

• Every few months, to step back from individual sprints.
• Teams new to Scrum, or changing how they apply it.
• When the team wonders whether its process is helping or hindering delivery.

Purpose: Review how your team works with Scrum, discover what is helping or hindering delivery, and agree on a small number of meaningful improvements.

The checklist is grouped from what matters most to what is optional:

• The bottom line · 3 practices

  The outcomes that matter most. If you achieve these, the checklist suggests you can ignore the rest — your process is fine.

• Core Scrum · 44 practices

  Practices the checklist treats as central to Scrum.

• Recommended but not always necessary · 28 practices

  Most of these will usually be needed, but not necessarily all of them. Experiment!

• Scaling · 3 practices

  Fundamental when several teams work on the same product. Not part of the score.

• Positive indicators · 3 practices

  Leading indicators of a good Scrum implementation.

Based on “The Scrum Checklist” by Henrik Kniberg / Crisp, version 2.2 (2010-10-04). An unofficial, subjective checklist — a conversation starter, not an official Scrum standard or a certification.

1. 1

   Set the context · 5 min

   Read the opening message and the three principles out loud. Agree which sprint or period you're looking back on, and stress that this is a conversation starter, not an audit.

2. 2

   Review the checklist · 15 min

   Tick together the practices that are in place — the score updates live. Everyone also answers on their own: start with the bottom line, then skip to the sections that matter most. Answers are anonymous and hidden until you move on.

3. 3

   Select discussion topics · 8 min

   Walk through the items the team flagged as Needs discussion or Unsure. Everyone votes for the topics that matter most; aim for one to three topics.

4. 4

   Discuss and understand · 15 min

   Take the top topics one at a time. Use the prompts to explore root causes before jumping to solutions, and capture insights as comments.

5. 5

   Create improvement actions · 8 min

   Turn the discussion into one to three small experiments. Give each an owner, a target sprint or date, a success signal, and link it to its checklist item.

6. 6

   Close the retrospective · 4 min

   Recap what to preserve, what you found, the actions you agreed, and what to check at the next retro. Then finish the retro.

Notes a software team might write:

Expected outcome: A weighted checklist score, a shared view of what's working, one to three topics explored in depth, and small experiments to try next sprint.

• Start with the bottom line: if those outcomes are fine, keep the rest of the review light.
• Score weights: bottom line 40%, core Scrum 40%, recommended 15%, positive indicators 5%. Scaling isn't scored. All three bottom-line outcomes in place = 100.
• A practice you achieve another way counts as in place — the purpose matters more than the practice.
• Re-run every few months and compare what changed.
• The score is for the team's own reflection. Never use it to rank or compare teams, or as a certification.
• Based on The Scrum Checklist by Henrik Kniberg / Crisp (v2.2, 2010) — an unofficial, subjective tool.

Each practice can be ticked as in place, which builds a live weighted score, and everyone answers anonymously whether it works well, needs discussion or is unclear. Flagged items become topics to vote on.

Each stage comes with instructions for the facilitator and the participants and a suggested timer you can adjust. Teammates join with a link and their name; no account needed.