Definition
Sprint Review
A sprint review is the event at the end of a sprint where the team demonstrates the working increment to stakeholders and gathers feedback. It is a working session, not a status meeting: the team shows what is actually done, stakeholders react, and the product backlog is adjusted in response. The output is an updated plan, not a sign-off.
Key takeaways
- A sprint review demonstrates the working increment to stakeholders at the end of a sprint and gathers their feedback.
- It is a collaborative working session, not a one-directional demo or a status report.
- Its key output is a revised, re-ordered product backlog reflecting what was just learned — not a sign-off.
- The review inspects the product (what was built); the retrospective inspects the process (how the team worked).
The sprint review closes the sprint by inspecting the product. The team shows the increment — real, working functionality, not slides — to the product owner and stakeholders. Everyone present examines what was built against the sprint goal, discusses what changed in the market or the business, and decides together what the most valuable next steps are.
It is easy to confuse the review with a demo or a status report, but it is neither. A demo is one-directional; the review is a collaboration. Stakeholders don't just watch — they react, and their reactions feed straight back into the product backlog. The single most important output is a revised, re-ordered backlog reflecting what was just learned.
The review pairs with the retrospective but inspects a different thing: the review examines the product (what we built), the retrospective examines the process (how we worked). Keeping them separate keeps each honest — product feedback in one room, team improvement in the other.
Planoda makes the review concrete by tying each sprint's completed work to the increment it shipped, so the conversation starts from what actually got done rather than from a status update.
Related terms
- ScrumScrum is an agile framework for delivering work in fixed iterations called sprints. A small cross-functional team plans a sprint, works without mid-sprint scope changes, then inspects and adapts through review and retrospective. Defined roles, events, and artifacts give the framework structure while leaving the actual engineering practices up to the team.
- SprintA sprint is a fixed, repeating time-box — usually one to four weeks — during which a Scrum team commits to a focused set of work and aims to ship a usable increment. It is the Scrum term for the iteration other frameworks call a cycle, giving the team a regular cadence for planning, focus, and review.
- RetrospectiveA retrospective is a recurring meeting, usually at the end of a cycle, where a team reflects on how it worked — what went well, what didn't, and what to change. Its output is a small set of concrete improvements to try next. The retrospective is the engine of continuous improvement, turning experience into deliberate process change.
- Definition of DoneA definition of done is a shared, explicit checklist of what must be true before any work item counts as complete — code reviewed, tests passing, documentation updated, deployed. It removes ambiguity about the word 'done,' preventing half-finished work from being declared finished and creating a consistent quality bar across the whole team.
- BacklogA backlog is the ordered list of all work a team has identified but not yet started — features, bugs, improvements, and ideas. It is the team's single source of pending work, prioritized so the most valuable or urgent items sit at the top, ready to be pulled into a cycle or onto a board.