Posts

Who should attend a retrospective meeting? (and who shouldn't)

Illustrated hybrid retrospective with some teammates around a table and others joining on a large video screen, everyone adding colorful sticky notes to one shared digital board

Kelly Lewandowski

Last updated 21/06/20266 min read

The short answer: the people who did the work, plus someone to facilitate. The Scrum Guide is clear that the retrospective belongs to the team, and for most sprints that's the whole guest list. The harder questions live at the edges. Should your manager sit in? What about a stakeholder who keeps changing priorities mid-sprint? And how does the answer shift when half the team is in a conference room and the other half is dialing in? That's what this guide is about.

The default attendee list

For a normal sprint retrospective, invite the people accountable for the sprint and nobody else:

The developers

Everyone who built, tested, and shipped the work. They have the closest view of what actually happened.

The product owner

Owns priorities and the backlog. The retro is where the team works out whether they're building the right thing in the right way.

The scrum master

Facilitates the process and owns follow-through on action items. On many teams this is also the facilitator.

That's the core. In Scrum terms it's simply "the team." Everyone here was in the trenches for the sprint, so everyone has something to contribute and a stake in what changes next. Every name beyond this list is a judgment call, and the default answer to "should we add this person?" is no.

Who shouldn't be in the room by default

The most common mistake is treating the retro as an open meeting. It isn't. Two groups get added too often. Managers and team leads. Even a supportive manager changes the conversation. People soften criticism and stop short of naming the real blocker. The person who signs off on promotions doesn't have to say a word to dampen honesty. Stakeholders. They have a forum for shaping the work, and it isn't the retro.

Belongs in the sprint retrospective	Belongs in the sprint review
The team that did the work	The team plus stakeholders and customers
Private, candid reflection on how you work	Open feedback on what you built
Process, communication, team dynamics	Product direction, priorities, roadmap

If your goal is to get stakeholders closer to the work, the sprint review is the meeting designed for exactly that. Keep the retro for the team.

Protect psychological safety

A retro only works when people can be honest about what went wrong, including their own mistakes. The moment someone with authority over careers or budget is watching, that honesty drops. Psychological safety is the whole point of a closed-door retro, not a nice-to-have.

When to invite stakeholders anyway

There are real exceptions. Invite a stakeholder when the team is stuck on something only that person can unblock, and keep the invitation narrow. Illustrated team in an open discussion around a table with one more formally dressed guest sitting slightly apart at the edge, listening rather than leading, conveying an invited observer

Illustrated team in an open discussion around a table with one more formally dressed guest sitting slightly apart at the edge, listening rather than leading, conveying an invited observer

A blocker the team can't fix alone

A dependency on another team, a stakeholder who keeps changing scope mid-sprint, or an approval process slowing everything down. Invite the specific person to the specific topic, not the whole retro.

A new team or working relationship

When a team and a key partner are still figuring each other out, a one-off joint retro can build empathy fast. Do it deliberately, not as a standing invite.

A milestone or project retrospective

After a major release or at the end of a project, a wider retro with stakeholders is appropriate by design. This is a different meeting from your sprint retro, with a broader scope.

If you do invite someone, set the rules first

Brief the guest beforehand: they're there to listen and answer questions, not to direct or defend. Better yet, split the session. Run the first half team-only, then bring the guest in for the topic that needs them. Never spring an outside attendee on the team without warning.

How remote and hybrid teams change the answer

Illustrated remote team members in separate home offices, each on their own screen, contributing sticky notes to a single shared digital retrospective board in the center

Distributed teams don't change who's accountable, but they change how attendance actually plays out. The hybrid trap. The worst setup is a few people in a conference room with everyone else dialed in. The room dominates, remote folks become spectators, and side conversations happen off-mic. Pick one: everyone in the room, or everyone on their own screen. A "fully remote even when some are in the office" rule keeps the playing field level. Async input changes who gets heard. When people add items to the retro board before the live session, attendance stops being about who talks fastest in a 60-minute window. Quieter teammates and those in awkward time zones contribute on equal footing. Anonymous voting matters even more here, where screen presence and power dynamics get amplified. A second facilitator for large distributed groups. Someone to watch the chat, the board, and the faces you can't read across a gallery view, so nobody gets talked over. Who attends and when they attend are different problems. If your team spans time zones, scheduling is the harder one, and we cover it in depth in running agile ceremonies across time zones. Either way, a quick icebreaker helps warm a distributed group up before the real conversation starts.

Special cases

Large teams (more than ~10 people). Big groups make for quiet retros: airtime per person drops and the loudest voices win. Split into smaller sub-groups for the discussion, then share key themes back to the whole team. Or run a focused retro for just the people who worked on a specific epic. Multiple teams. Don't merge everyone into one giant retro. Run team-level retros first, then a short cross-team retro with one or two representatives from each. Representatives bring themes up, not raw detail. Brand-new teams. Keep the circle tight while trust is still forming. This is the worst time to add observers. Build safety first; widen the invite later if it ever makes sense.

A simple test for any invite

When you're unsure whether to add someone, ask one question: will this person's presence make the team more honest, or less?

They did the work this sprint, or own a blocker the team genuinely can't resolve alone

Their presence will make people more candid, not less

They've been briefed that they're there to listen, not direct

The team knows in advance who's joining and why

If you can't check all four, keep them out. They belong in the sprint review, the next planning session, or a separate conversation.

The bottom line

Default to the team that did the work plus a facilitator. Treat every other invite as the exception it is, and reserve stakeholder relationships for the sprint review where they belong. Get the room right and the rest of the retro gets easier. Kollabe's retro boards are built for this: async input so everyone contributes before the discussion, anonymous voting to keep it honest, and action items you can track into the next sprint. New to running them? Start with our guide to running an effective retrospective.

Usually no. A manager's presence makes people soften criticism and avoid naming real problems, which defeats the purpose. If a manager needs visibility into the team's improvements, share the action items afterward rather than seating them in the room.

When the team is blocked on something only that stakeholder can resolve, or for a one-off milestone retrospective. Keep the invitation narrow, brief them to listen rather than direct, and consider running the first half team-only.

Typically the scrum master, but it can be an agile coach or any neutral person not deep in the work. The facilitator keeps the session on track, makes sure everyone is heard, and guides the group toward action items.

Avoid the hybrid split. Either gather everyone in person or have everyone join from their own screen. Collect input on a shared board before the live discussion so remote teammates contribute on equal footing.