Flocci Projects

Home › Agile answers › What happens in a sprint review?

What happens in a sprint review?

A sprint review is where the team demonstrates completed work to stakeholders and collects feedback that reshapes the backlog. It is about the product. The retrospective, held separately, is about the process. Mixing them means one of the two conversations always gets crowded out — usually the process one.

Demo, do not present

Show the working software, not slides about the working software. Only items meeting the definition of done get demonstrated; showing something 'nearly done' trains stakeholders to believe estimates that have not been earned yet.

The output is backlog change

A sprint review that ends in applause and no backlog edits was a status update. Real feedback reorders priorities, splits an item, or kills something — capture those changes on the backlog during the meeting while the reasoning is still attached.

Who should be there

The team plus whoever the work is for: the product owner, a founder, a customer-facing colleague, sometimes an actual customer. The value scales with how close the audience is to the person who feels the problem.

Try it on a free Flocci Projects board

Related questions

How long should a sprint review take?

Thirty to sixty minutes for a two-week sprint. If demos consistently overrun, the sprint is carrying too many disconnected items — which is itself a planning signal worth naming in the retrospective.

What about work that did not get finished?

Mention it briefly and move it back to the backlog; do not demo it. Explaining unfinished work in detail turns the review into a defence, which is precisely the dynamic that makes teams hide problems.

Can the review and retrospective be one meeting?

For very small teams, back-to-back with a clear break between them works. Merging them entirely does not — product feedback is louder and more urgent, so it reliably consumes the time the process conversation needed.

More agile answers