Sprint Review: Agenda, Who Attends and How to Run It

Lena's team spent Friday morning polishing slides for the sprint review. Eleven people joined, watched 25 minutes of guest checkout screenshots, said "nice work," and left. Three days after release, the support lead mentioned what she'd have said if anyone had asked: guest customers can't find their order afterwards. (Lena's team is a composite, not a real team.)

You've probably sat through that meeting. It feels fine and changes nothing, because the people who know the customer never touched the product.

This guide gives you an agenda timed for one- to four-week sprints, what the Scrum Guide says (checked in November 2026), an invitation to copy, sprint review vs retrospective, and a one-page record of what got decided.

What is a sprint review?

A sprint review is the Scrum event where the team and its key stakeholders look at what got finished, talk about what's changed around the product, and decide what to do next. In the words of the 2020 Scrum Guide, its purpose is "to inspect the outcome of the Sprint and determine future adaptations."

It's the second to last event of the sprint. The retrospective meeting comes after it, and then the next sprint planning meeting picks up whatever the review changed.

Sprint review agenda: timings for any sprint length

Pick your column and paste the minutes into the invite. These timings are our suggestion, not a Scrum rule, and they use about 30 minutes per sprint week, half the guide's maximum.

Want the decisions written down without a note-taker? Put ParrotNotes on the table and get a summary and action items when you stop recording. Try ParrotNotes free.

1. Open with the goal

The Product Owner states the Sprint Goal, says whether it was met, and lists what was finished and what wasn't. Give the bad news first.

2. Inspect the finished work

Show the working product, not slides. Better still, hand over the keyboard and ask a stakeholder to try a real task while the Developers watch. Share the list of items the night before, so people arrive with questions.

3. Ask what has changed

The guide wants the group to review "what has changed in their environment." So ask sales, support, and finance directly. A new competitor or a budget cut can matter more than anything you built.

4. Check the Product Goal

Say where the product stands against its longer-term goal, in one or two sentences.

5. Decide what's next

This is the step that gets squeezed. Go through what you heard, and let the Product Owner add, reorder, or remove backlog items. You don't need a final plan today, just a backlog that reflects what the room learned. Sizing and splitting the new items is work for the next backlog refinement session.

6. Read back and close

Read the backlog changes and owners aloud, then send the record the same day.

What the Scrum Guide says, and what it doesn't

The guide gives this event one short section, and it's blunt about the most common mistake: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation."

We searched the guide's text for the words teams usually attach to this meeting:

• "Demo" isn't there. Neither is "feedback." A demo can be part of a review, but the guide's point is collaborating on what to do next.
• "Sign-off" and "approve" aren't there either. "Accept" appears only in phrases about process and product falling outside acceptable limits. The review isn't where the Product Owner accepts the work.
• It isn't a release gate. "The Sprint Review should never be considered a gate to releasing value." You can ship on day three and discuss it here.
• Unfinished work stays out. "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration." Name it in step 1, and don't show it in step 2.

The timebox is "a maximum of four hours for a one-month Sprint," and the guide only says shorter sprints are "usually shorter." Published advice for shorter sprints varies. As of November 2026, Atlassian recommends "30 minutes to an hour for each iteration," LogRocket uses one hour per sprint week, and Spark Academy budgets 90 minutes for two weeks. Start short, and add time only if step 5 keeps running out.

Who attends a sprint review

The whole Scrum Team attends, along with the key stakeholders. The guide doesn't say who runs it or who sends the invite, but Scrum.org describes "key stakeholders invited by the Product Owner," and that's the usual setup.

Who counts as key? Anyone who can tell you something the team doesn't know, or who'll act on what's decided. Eleven people for an hour is 11 person-hours, and our meeting cost calculator shows what that costs.

Copy this invitation:

Subject: Sprint review, [date], [start] to [end]: try [feature]

Hi [name],

This is a working session, not a presentation.

The goal was: [Sprint Goal, one sentence]
You can try: [2-3 finished items]
We'd like your view on: [one specific question for this person]

Please bring anything that has changed on your side: customers,
competitors, budget, deadlines. I'll send a one-page record the same day.

[Product Owner]

The specific question matters most. "Would your team use this tomorrow?" gives someone a reason to come, and "see our progress" doesn't.

Sprint review vs retrospective: what's the difference?

The sprint review looks at the product with stakeholders. The sprint retrospective looks at how the team worked, without them. Both happen at the end of the sprint, in that order.

A team discussing what went wrong with stakeholders watching can go quiet, so keep the two apart. Here's a quick test for any comment: does it change what we build, or how we work?

Our retrospective template is free if you want a board for the second meeting.

How to run a sprint review when it drifts

Keep these lines ready:

On that promise line, the guide says "Those wanting to change the Product Backlog can do so by trying to convince the Product Owner." A review is where you make your case, not where you get a date.

This works outside software too. Picture a composite marketing team of four, reviewing a webinar page that went live during the sprint. A sales rep tries the form on her phone, gets stuck on the seventh field, and says so. By the end of the hour, shortening the form tops next sprint's list.

Sprint review template: the one-page record

The guide doesn't ask for minutes, but sprint planning needs these answers. Copy this into your team's doc.

SPRINT REVIEW RECORD
Team:              Sprint:              Date:
Facilitator:       Product Owner:       Stakeholders:

1. SPRINT GOAL (met? yes / partly / no)

2. DONE

3. NOT DONE (back to the backlog)

4. WHAT HAS CHANGED

5. PRODUCT GOAL: where we stand

6. BACKLOG CHANGES
   Item | New, moved or removed | Owner

7. OPEN QUESTIONS
   Question | Who answers | By when

Here it is filled in, using the composite team from our planning guide:

SPRINT REVIEW RECORD
Team: Checkout squad    Sprint: 42    Date: Nov 20
Facilitator: Lena    Product Owner: Ana
Stakeholders: Joy (support), Ravi (sales), Mei (finance)

1. SPRINT GOAL
   Returning customers can pay with a saved card. Met: yes

2. DONE
   Saved card storage, card picker at checkout,
   payment token migration, flaky checkout test fixed

3. NOT DONE
   Declined card error messages

4. WHAT HAS CHANGED
   A competitor launched one-tap checkout.
   Card processing fees rise in January (Mei).

5. PRODUCT GOAL: repeat customers check out in under a minute
   Now 1 min 40 s with a saved card, down from 3 min

6. BACKLOG CHANGES
   Expired card flow | New, ranked 1 | Ana
   Declined card error messages | Moved, ranked 2 | Ana
   Apple Pay | Moved up, ranked 3 | Ana

7. OPEN QUESTIONS
   Does the January fee change card order at checkout? | Mei | Nov 24

Section 6 feeds straight into the next plan. Move the open questions into your action items tracking log, and see our meeting cadence guide for spacing this around your other recurring meetings.

Should you record the review?

Recording lets the Product Owner listen rather than type during steps 3 and 5. Ask first, say what you'll keep and who'll see it, and stop if anyone objects. Consent rules vary by location, and our guide to one-party consent states covers the US basics.

ParrotNotes records on a phone or Mac in the room, with no meeting bot, and gives you a transcript, a summary, and action items to paste into the record. As of November 2026, recordings can run up to 3 hours on Pro ($19.99 a month, or $14.99 a month billed annually).

The free plan allows 30 minutes per recording and 100 minutes a month, so skip the first four steps and record steps 5 and 6. On a two-week sprint, that's about 20 minutes, and it's where the decisions are. Download ParrotNotes and try it at your next review.

Make your next review a working session

A good sprint review gets you an honest account of what's Done, news from outside the team, and a backlog that reflects both. Put the goal and unfinished work up front, hand over the keyboard instead of showing slides, ask each stakeholder one specific question, and send one page the same day.

Lena's team dropped the slides for Sprint 42. Joy from support took the keyboard, tried an expired saved card within four minutes, and hit a dead end. Ana put the fix at the top of the backlog before the hour was up, and this time nobody heard about the problem from a customer first.