Who should attend the Sprint Review

The Sprint Review is only as useful as the people in it. A room of Developers and a Product Owner can confirm that the work was done, which is something the team already knows. A room with a person who will use the product on Monday, a person who pays for it, and a person who has to support it tells the team something new. Choosing the audience is therefore part of the design of the event, and it falls to the Product Owner.

What the sources say

The Guide's wording is that the Scrum Team presents the results of its work to key stakeholders and progress toward the Product Goal is discussed. The attendees collaborate on what to do next, and the Product Backlog may be adjusted to meet new opportunities. The event is a working session, and the Guide advises the Scrum Team to avoid limiting it to a presentation.

The word "key" matters. It does not say all stakeholders, or any stakeholder who asks. It points to the people whose input will change decisions.

The SBOK® Guide encourages business stakeholders to participate in the Sprint Review Meeting to gain first-hand knowledge of the product and its progress and to provide feedback, which is an important input to future Sprints. It also divides business stakeholders into customers, users and sponsors, and in the Demonstrate and Validate Sprint process names the Product Owner as the person who accepts or rejects the stories against the agreed criteria. So the SBOK sets a more specific role for the Product Owner at the event and shares the Guide's view of stakeholders as contributors.

A way to build the list

For each potential attendee, ask three questions.

1. Do they know something the team does not? Users know how the product is actually used. Support staff know where it fails. Operations staff know what is costly to run.
2. Can they decide something that changes the backlog? A sponsor can change priorities or funding. A compliance lead can add constraints.
3. Will they be affected by what they see? People who must adopt, sell or support the product should not be surprised later.

A person who answers yes to at least one belongs on the list. A person who answers no to all three can read the notes.

It also helps to think of groups rather than individuals, and to check each is represented:

• Users or their representatives. The most valuable feedback on whether the product works.
• Sponsor or budget holder. The person who decides whether to keep investing.
• Customer, where it differs from the user. Whoever acquires the product.
• Operations, support or sales. People who will deal with the consequences.
• Neighbouring teams. Teams that depend on, or are depended on by, the Increment.
• Specialists on particular items. Security, legal, accessibility, brought in when the Increment touches their area.

A worked example

This is an illustrative case. A team has built a new cancellation flow for an appointment service. The Product Owner starts with a list of fourteen people, which includes everyone who ever expressed interest.

She applies the three questions. Two support agents, who handle most cancellation complaints, know what customers actually say. A customer-experience lead decides how the flow is measured. The sponsor decides whether the next Sprint's goal should continue this work. A payments specialist is affected, since refunds are involved. A compliance officer needs to see the refund rules. Of the remaining nine, five have only a general interest, three are managers who want a briefing, and one is on leave.

The final list has seven names, plus the Scrum Team. The Product Owner sends a short invitation with the Sprint Goal, a statement of what will be shown and the questions the team would like answered: does the refund wording make sense, and is the new flow quick enough for an agent to explain on the phone. The five people of general interest receive a short written summary and the invitation to the next Review. The managers receive the notes.

At the event the support agents point out that a customer who cancels twice sees a confusing message. The sponsor, who had been about to prioritise a new report, asks the Product Owner to move the cancellation fix up. The Product Backlog changes in the room. That is the Guide's intention.

Signs you have the wrong people

• Nobody asks a question. The audience is either too deferential or too indifferent.
• Everyone is a team member. There is no outside view.
• Only managers attend, and no users. The feedback will be about confidence and not about use.
• The group is too big to talk. A working session of more than about twelve to fifteen people becomes a presentation. This is a practical limit and not in the Guide.
• The same people attend every time but never change anything. They may be on the list out of habit.
• Key decision makers are absent. The Review then cannot adjust the backlog, and the Product Owner has to chase approvals.

Preparing the people you invite

An invitation that says "Sprint Review, Thursday 2pm" gets a blank reaction. A useful one says what the Sprint Goal was, what will be shown, what the team wants help deciding and how long it will take. Stakeholders who know the questions arrive with an opinion. Those who do not tend to wait to be impressed.

It also helps to say what the event is not. It is not a sign-off meeting, and it is not a place for new feature requests to be agreed on the spot. The Product Owner can take requests and order them in the backlog afterwards, with reasons. Saying this early prevents the awkward moment when a senior visitor assumes a verbal request is a commitment.

Practical points

The Scrum Master helps with logistics, and the Guide says they ensure events take place and are positive and productive. The Product Owner invites, ensures attendees are prepared, and brings the right questions. Stakeholders who cannot attend can send questions in advance or comment on a recording. A recording is a supplement and not a replacement, since the value of the event is in the exchange.

Be careful with closed-door versions. Some organisations keep the Review internal because the product is sensitive or the stakeholders are numerous. In that case, invite representatives who can bring views from the wider group, and report back.

The Agile Manifesto's principle that business people and developers must work together daily applies in spirit. The Review is the one regular point where the circle widens beyond the daily pair.

How to practise it

Write your invitation list with a reason beside each name. Remove anyone whose reason is "to keep them informed". In the simulator the Sprint Review at step 4.1 involves a Sponsor and stakeholders, so you can see how their different concerns shape what happens to the backlog.