Sprint review vs retrospective: stop making them share one hour

It is Thursday afternoon and there is one hour on the calendar called "Sprint review". Two stakeholders join, a laptop gets shared, and for twenty-five minutes the team walks through what it built. The stakeholders say "nice, looks good", one of them has to jump to another call, and they both drop off. The remaining twenty minutes are the team, alone, complaining about the build pipeline. Nobody writes anything down. Everyone leaves feeling the hour was fine, and nothing changes.

That hour was two different meetings sharing one slot, and neither of them happened. The sprint review is an outward-facing conversation about the product with the people who care about the product. The retrospective is an inward-facing conversation about how the team works, held by the team alone. Different audience, different question, different meeting. Small teams collapse them because an hour is cheaper than two hours, and the thing they save is the only part that produces change.

What the Scrum Guide actually says

Worth being precise here, because both meetings get described loosely and then run loosely. The 2020 Scrum Guide calls them events, not ceremonies, and it is quite specific about each.

On the review: "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." Then the line that most teams are violating: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation."

On the retrospective: "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done." Note who is doing the inspecting. The Scrum Team. Stakeholders appear in the review section and not in this one.

The timeboxes are worth quoting exactly, because they are routinely misremembered as targets. The review "is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter." The retrospective "is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter."

So Scrum's ceiling for a monthly sprint is seven hours across the two. The guide gives no formula for shorter sprints, only that hint that they are usually shorter, and halving is the common reading: roughly two hours and ninety minutes for a two-week sprint. Those are ceilings. A good review on a two-week sprint fits in forty-five to sixty minutes and a good retrospective in forty-five. The point is not that your one hour is too short. It is that one hour with one guest list cannot hold two audiences.

Who belongs in each room

The review's guest list is the team plus the people whose decisions depend on the product: the product owner, obviously, but also the support lead who fields the complaints, the sales engineer who keeps promising this feature, the client paying for it. If nobody in the room can change their mind about what to build next, you have not invited stakeholders, you have invited an audience.

The retrospective's guest list is the Scrum Team. That is it.

Should stakeholders be in the retrospective?

No, and the reason is not etiquette or tradition. It is that a large share of what a team genuinely needs to discuss is the pressure arriving from outside the team.

Go through a few real retrospective topics. Scope changed on day four because someone senior asked. A story sat blocked for three days waiting on a decision from a person who was travelling. The team took on an "urgent" request that turned out not to be urgent, and shipped two planned stories instead of four. Every one of those has an owner who is a stakeholder, not a developer. Put that person in the room and the item does not get raised at all, or it gets raised in a softened, deniable form that leads nowhere. You do not get a diluted retrospective. You get a fake one, and then people learn the meeting is theatre and stop bringing anything real to it.

The counter-argument is decent and I want to give it properly: teams and stakeholders are one system, so improving only half of it in private is a bit absurd, and the person causing the friction is the one who could most easily stop. True. There is a version of this that works, and it is a deliberately separate session: a joint review of how the team and its stakeholders work together, scheduled on purpose, framed to everyone in advance, ideally facilitated by someone who is not in either camp. Run that once a quarter if the boundary is where your real problem lives. What does not work is quietly adding your head of sales to the standing retrospective invite and hoping candour survives.

One honest complication. On a small team the line genuinely blurs, because the product owner is often the person applying the pressure and is also, correctly, part of the Scrum Team. They belong in the retrospective. If your team cannot say "requirements arrived late twice this sprint" in front of its own product owner, the format is not the problem you need to fix first, and no seating arrangement will solve it. The blameless framing is what makes that conversation survivable.

And when a manager asks to sit in, say what it is for rather than quoting a rulebook at them. "It only works if people can be blunt about things you're involved in, so the review is the meeting where your input changes the most" is a true answer, and it usually lands.

A sprint review agenda that works

Forty-five to sixty minutes for a two-week sprint. Five parts, and the proportions matter more than the exact minutes.

1. Where the product stands against the product goal. Five minutes, spoken, no slides. Not a task-by-task status report: the one-sentence version of what is now possible that was not possible two weeks ago.
2. What changed outside the team. Five minutes, and this is the item everyone skips. A competitor shipped something. Support saw the same complaint eleven times. A customer's contract renews in October. Skip this and the review is just a demo, because there is no new information for anyone to react to.
3. The working software, in stakeholders' hands. Twenty-five to thirty minutes, the heart of it. Let them click. Screen-sharing while you narrate produces polite nodding; watching someone else fumble through the flow you built produces the actual feedback. Only show work that meets your definition of done, because a half-finished feature invites feedback on something that may still change underneath it.
4. What this means for the backlog. Ten minutes, out loud, while everyone is still present. The Scrum Guide's line is that the Product Backlog "may also be adjusted to meet new opportunities", and the review is where you do that, not in a private tidy-up afterwards. Reorder something. Kill something. Split something. If the backlog looks identical after the meeting, the meeting had no effect.
5. What next sprint is pointed at. Five minutes, direction only. The commitment happens in sprint planning, not here.

We used to think the reliable tell for a broken review was its length. It is not. It is who is talking. If the team holds the floor for ninety percent of the hour, you ran a demo, regardless of what the calendar says.

Why the review keeps degrading into a status report

Because for most stakeholders it is the only time they see anything. If the last two weeks were invisible to them, the first fifteen minutes of the review have to be spent catching them up, and the meeting turns into a report by pure necessity. Nobody chose that. The information gap chose it.

That gap is fixable, and it is mostly a tooling and permissions question. When stakeholders can open the board or the sprint any day they like, the review stops carrying the burden of being the update. It is worth being blunt about why teams do not do this: many tools charge a full seat for someone who only wants to look, so visibility gets rationed to the people who can justify a licence. In Scrumpy, view-only members are free and unlimited, which is a pricing decision rather than a feature, and it is the one that matters most for this meeting. If your client, your support lead and your CEO can watch the sprint burn-up move all week, none of them needs the review to tell them how far along you are, and you get the whole hour for the product instead. We wrote about the wider version of that argument in stop paying for view-only seats.

The same logic is why a good daily standup is not a status meeting either. Status wants to be ambient. Meetings should be for the things that need a decision.

The retrospective, in one paragraph

The retrospective follows the review, ends the sprint, and asks a single question: how do we work a bit better next time? Reflect honestly on how the sprint actually went, then commit to one or two specific changes with names attached, and check at the start of the next one whether they happened. That loop is the whole thing, and we have written the long version in how to run a sprint retrospective your team doesn't dread. If you take one habit from it, take the small number of actions. One change that lands beats eight that get noted.

The cheapest fix available

Two calendar invites instead of one, with the stakeholders on only the first.

That sounds trivially small, and it is the fix. A single event guarantees the review runs long, because reviews always do when someone finally asks a good question at minute fifty. Whatever is left goes to the retrospective, which is how you end up with twenty minutes of pipeline grievances and no decision. Two invites make the boundary real. It also gives the team the small gap it needs to switch modes, from talking to guests about the product to talking to each other about themselves, which is a genuinely different kind of conversation and not one people can pivot into mid-sentence.

Make the split this week and watch which meeting you were actually short of. Most teams find the review was fine and the retrospective had never really existed. If you want somewhere to put the changes that come out of the second one, park them as visible cards on your board beside the real work, where they have to compete for attention like everything else.