Which ceremonies a client should be in

Every access decision here reduces to one question. If the client is in the room, does the meeting still do its job?

For the sprint review the answer is that the client's presence is the point. Atlassian describes it as the session where the team presents completed work to stakeholders, demonstrates it, and gathers feedback, noting that it is outward-facing and involves stakeholders while the retrospective is an internal team meeting.

For the retrospective the answer is no, and the reason is not politeness. The retrospective's value comes from people saying things that make them look bad: that they underestimated, that they did not ask for help, that a decision was wrong. Nobody says any of that to the person paying the invoice, and a team that tries produces a sanitised version which is worse than no meeting, because it consumes the slot where the real conversation would have happened.

Once you apply that test the access model writes itself, and it stops being a matter of how close you are to the client.

The rows that need defending are planning and standup, because both invitations sound reasonable and both damage the meeting.

The last column is the operative one. Every no in this table is paired with something better, and refusing access without offering a substitute is what makes the conversation adversarial. A client asking to join the standup wants daily visibility, which is a legitimate want and cheaply satisfied without them being in the meeting.

This is where a client should spend their attention, and most agencies under-invest in it because it feels like a demo rather than a decision point.

Atlassian's account of what happens in the session is a good specification: the team demonstrates completed work, discusses what was accomplished, what remains unfinished, and any changes to the backlog, and the product owner reprioritises upcoming work based on the feedback received. That last clause is the part agencies skip. A review that ends without the backlog changing was a presentation.

Two rules make it work with a client present. Show only what is finished, against the agreed definition of done. Showing work in progress trains the client to believe things are further along than they are, and you will pay for that at the end. And leave real time for feedback rather than filling the slot with demonstration, because the feedback is what you came for.

Keep it informal. Atlassian notes that its own reviews are casual sessions where team members describe their work and people ask questions and try features. A rehearsed presentation invites a client to behave like an audience, and audiences do not give useful feedback.

Planning has two halves that get run as one meeting, and only the first half concerns the client.

The first half is what should be built next. That is the client's call, informed by whatever they have just seen at the review. The second half is how the team will build it, which is a technical conversation the client cannot contribute to and which changes character when they are watching.

The damage from keeping them for the second half is specific. Team members stop saying that something is harder than it looks, because that sounds like an excuse in front of the buyer. Estimates drift downward. Nobody flags the risky part. You get a plan that everyone in the room privately doubts.

Splitting is easy. The client joins for the first portion, sets priority, answers questions, and leaves. Atlassian's guidance on planning duration is about an hour per week of iteration, so a two-week sprint gets roughly two hours and the client needs perhaps the first thirty minutes of it.

Tell them why in advance and it is a non-issue. "The first half is your call and we want you there. The second half is us working out how, and it goes faster if we can argue about it." Every client I have said that to has been relieved.

Atlassian describes the daily as a short meeting of fifteen minutes or less to discuss progress and identify blockers, and is explicit that it is not a detailed status meeting. That is exactly what it becomes when the client joins.

The mechanism is not subtle. Once the buyer is present, each person is reporting to them rather than coordinating with each other. Answers get longer and more defensive. Nobody says they are stuck, because being stuck in front of the client feels like a confession. The one function the meeting has, surfacing blockers early, is the first thing to go.

Substitute a written daily line and most clients are more satisfied than they would have been by attending. One short message: what finished yesterday, what is in flight, what we need from you. It is asynchronous, they can read it at a convenient time, and the third item is the part they actually care about.

There is a client-side version worth offering where the engagement genuinely needs a daily touch. A five-minute call between the delivery lead and the client contact, right after the team's standup, carrying the same three points. That gives the client the daily rhythm without putting them inside the team's coordination.

Atlassian frames the retrospective as the ceremony where a team reflects on what happened and identifies actions to improve, and suggests roughly forty-five minutes per week of iteration. The value is entirely proportional to how honest people are willing to be.

So it stays internal. Not because clients are the enemy, but because the meeting's function requires an environment where admitting a mistake carries no commercial consequence, and no amount of goodwill removes the commercial consequence when the buyer is present.

What you can offer instead is a joint improvement review at a longer cadence, perhaps quarterly, with a different and honest purpose: what is working in how the two organisations work together, and what is not. Client delay, unclear feedback, and approval bottlenecks are all fair subjects and none of them belongs in a team retrospective anyway.

That meeting is genuinely valuable and it is the one most agencies never hold. It is also where the awkward findings from your internal retros get converted into a client conversation, which is the only way most of them ever get fixed. The blocked-day totals that make that conversation concrete depend on the vocabulary in issue, risk or blocker.

Every problem in this article is trivial when the rule is agreed in week one and painful when it is invented in month three in response to a request.

Four lines are enough in the engagement setup: which sessions the client is invited to, which they are not and why, what they get instead, and who from their side attends. That belongs with the rest of the setup covered in a project charter someone actually reads, and it needs to say which named person holds the priority decision, per the accountability grid in a RACI that survives a real project.

One thing to get right on their side: the person who attends the review must be able to reprioritise. A stakeholder who can only observe turns the review into a report and pushes the real decision into a separate meeting a week later, which costs you the iteration. Working out who that person is, before kickoff, is the subject of stakeholder mapping for a mid-market client.

None of this replaces written reporting. Attendance is not a report, and a client who was in the review still needs the artifact that tells them where the engagement stands, in the format that suits them. Which format that is, and what each one hides, is compared in status report formats compared.