The sprint review and retrospective are the two feedback loops that make agile development self-correcting. The sprint review gives the business a regular, structured view of the increment being built — not a progress report, but a working demonstration of done work — and gives the product owner the feedback to refine and reprioritise the backlog. The retrospective gives the team the structured space to examine how they worked during the sprint — what helped, what hindered, what to change — and to commit to specific, time-bound improvements. When these ceremonies work well, they create a compounding improvement dynamic: the product gets progressively closer to what the business needs because the business sees it regularly; the team works progressively better because they reflect systematically on how. When they do not work well — when unfinished work appears in demos, when retrospective actions are forgotten before the next standup, and when the backlog is not updated with the feedback collected — they become overhead rather than value. A structured sprint review and retrospective checklist ensures both ceremonies fulfil their intended purpose. This free checklist gives scrum masters, product owners, and development teams a structured framework for the full sprint review and retrospective cycle.
This checklist covers both end-of-sprint ceremonies in six phases — from sprint closure preparation through to the sprint record and handover.
Only work that meets the definition of done is presented in the sprint review. Unfinished work is not shown — it is moved back to the backlog, re-estimated where necessary, and represents a commitment that was not met. Presenting unfinished work as done erodes trust faster than any missed deadline.
The retrospective is the team ceremony most frequently skipped under time pressure. It is also the ceremony with the most long-term compounding value. A team that consistently reflects and improves how it works will outperform a team of individually more talented people who do not.
CheckFlow’s sprint review checklist separates the two ceremonies into distinct phases — the external-facing increment demonstration and the internal team reflection — ensuring each runs to its intended purpose. The definition-of-done check prevents unfinished work from appearing in the demo. The retrospective phase requires a specific number of actionable commitments, not a general discussion.
The retrospective action that is discussed and not documented is the retrospective action that is not implemented. CheckFlow’s retrospective phase creates a task for each committed improvement, assigns it to a named owner, and carries it forward into the next sprint board as a tracked item — visible alongside development work.
Sprint-over-sprint velocity data, sprint goal achievement rates, and the history of retrospective actions taken are the raw material for quarterly engineering health reviews and continuous improvement reporting. CheckFlow records all three automatically as the sprint review process runs.
The sprint review feeds into the sprint planning for the next sprint. CheckFlow’s Sprint Planning Checklist covers the structured planning ceremony. See the Sprint Planning Checklist →
User feedback collected during sprint reviews feeds the product backlog. CheckFlow’s User Feedback Collection Checklist in the Product Development & Launch series covers the systematic collection of user signals. See the User Feedback Collection Checklist →
A sprint review and retrospective checklist covers six phases: sprint closure preparation (definition-of-done verification, incomplete story management, velocity calculation, sprint goal assessment), demo preparation (demo environment, developer-led demo narratives, attendee confirmation), sprint review ceremony (context presentation, sprint goal outcome, increment demonstrations, stakeholder feedback collection, product owner roadmap update), backlog update (feedback logging, backlog updates, incomplete story re-estimation), sprint retrospective (what went well, what could improve, 1–3 specific improvement actions with owners and deadlines, review of prior retrospective actions), and sprint handover (sprint record, retrospective actions on next sprint board, summary sharing, next planning session confirmed).
The definition of done (DoD) is the agreed list of criteria that every user story must meet before it can be considered complete and included in the sprint increment. A typical DoD for a software product includes: code written and reviewed by a peer, automated tests written and passing, deployed to the staging environment, QA testing completed and passed, acceptance criteria verified, and documentation updated if required. Only stories that fully meet the DoD are presented in the sprint review. Stories that do not meet the DoD return to the backlog — they are not “90% done” stories presented with caveats; they are incomplete work that does not form part of the sprint increment.
An effective sprint retrospective is: structured (a consistent format that prevents the session from becoming a general complaint forum), psychologically safe (team members feel able to raise issues without personal consequences — the scrum master’s most important role is creating this safety), specific (observations about what happened, not character judgments), actionable (specific improvement commitments with named owners and deadlines, not vague resolutions), and accountable (prior retrospective actions are reviewed at the start of every retrospective — this is the single most important practice for making retrospective actions stick).
The sprint review should include the full scrum team (developers, product owner, and scrum master) and the key stakeholders who can provide meaningful feedback on the increment and inform backlog priorities. Stakeholders might include business owners, customers, end users, or representatives from other departments that depend on the product. The retrospective is attended by the scrum team only — no stakeholders. The psychological safety of the retrospective depends on it being a team-only forum.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
