If you’ve recently moved into a SaaS or tech environment from corporate learning, project management, or operations, you’ve probably sat in a room where someone said, “Time for sprint planning,” and you had no idea what was about to happen. The ceremonies of Agile—Sprint Planning, Daily Stand-Ups, Sprint Reviews, and Retrospectives—can feel like insider vocabulary designed to confuse people. They’re not. They’re actually designed to be simple. What went wrong is that most teams have let them drift into something closer to bureaucratic theater.
Let me walk through what each ceremony is actually supposed to do, what a healthy version looks like, and the warning signs that yours has curdled.
Sprint Planning
A sprint is just a fixed window of time—usually two weeks—where a team commits to doing a set of work. Sprint Planning is the meeting where you decide what goes into that window.
Here’s what it should be: the team and the product manager look at the prioritized backlog together. The team asks questions. “Do we understand what ‘done’ looks like?” “Is this dependent on anything outside our control?” “Have we missed something?” The PM answers. If there’s major confusion, items get sent back to be refined. Once everyone agrees on what’s doable and clear, the team commits to the sprint goal. Then you’re done.
That should take an hour or ninety minutes. Not four hours. Not spread across two meetings. Not with seventeen Slack threads that continue the conversation offline because nobody could agree in the room.
A sign yours has drifted: People keep updating estimates during the sprint, which means you didn’t actually understand the work before you started. Or the conversation in planning was purely about estimates, not about clarity. Or the PM presents items that aren’t ready, and the team is using planning as the refinement session—which means refinement isn’t happening upstream, and your planning is bloated.
Daily Stand-Up
This one is short enough that I’m genuinely confused by how many teams screw it up.
The stand-up is fifteen minutes. Everyone says: what did I finish yesterday, what am I working on today, is anything blocking me. That’s it. The purpose is synchronization—everyone knows what’s moving and where the impediments are. It’s not a status report to management. It’s not a performance review. It’s not a moment for the most senior engineer to question why someone is working on something.
A good stand-up feels fast and useful. You hear about a blocker, someone unmutes and offers help. Someone finishes something, the team knows they can start the next piece of dependent work. You’re out in fifteen minutes.
When it drifts: People start using it as a forum to discuss solutions (“Well, we could use Redis…” “Actually, the database query…”), and suddenly you’re thirty minutes in and three people are confused about why they’re still in the meeting. Or the manager is in the room looking for status updates, so people optimize for sounding productive instead of being honest. Or it becomes a ceremony people join but don’t really engage with—they’re reading their Slack while someone drones through their status.
In remote environments, some teams have gone async—a Slack thread or daily video update. That can work if people actually read it and respond to blockers. Most teams that try this end up with everyone recording a two-minute video that nobody watches, which defeats the entire purpose.
Sprint Review (Demo)
At the end of the sprint, the team shows what they built. Not in a “let me tell you about this in PowerPoint” way. In a “here’s the feature, here’s what it does” way.
A good sprint review is short and real. The team boots up the product, walks through what’s new, shows it to whoever cares (PMs, stakeholders, other teams). People ask questions. “How does that handle edge case X?” “Have you thought about Y?” This is actually valuable—it’s where you surface assumptions that nobody had a chance to surface earlier, and it’s usually low-stakes enough that people feel okay speaking up.
It also serves a purpose for the team: it’s momentum. You see what you shipped. It matters.
When it drifts: The team is demoing half-finished work because the sprint was too ambitious. Or stakeholders don’t show up because they never do, so it becomes a perfunctory meeting the team runs through. Or someone is doing a detailed technical explanation instead of showing the feature actually working. Or it becomes a performance where the team is trying to look impressive instead of being honest about what they shipped and what they learned.
Retrospective
This is the most important and most misused ceremony.
The retro is meant to be the team’s chance to reflect on how they worked, not just what they shipped. “What’s working? What’s not? What should we try differently next sprint?” If it works, it leads to actual behavioral change. If it doesn’t, it’s just an awkward conversation where everyone says “communication” and then nothing changes.
A healthy retro creates psychological safety—people feel like they can be honest without it being weaponized in a performance review. There are no managers in the room evaluating people. The facilitator (usually a Scrum Master or PM, though it should rotate) is good at staying neutral and actually following through: if the team says “we need better clarity on requirements,” someone owns making that happen and reports back at the next retro.
There are different formats that work: Start/Stop/Continue (what should we start doing, stop doing, keep doing), 4Ls (Liked, Learned, Lacked, Longed For), even a simple “What went well, what didn’t, what’s one thing we’ll try differently.” The format matters less than the follow-through.
When it drifts: You get the “what went well” answer where everyone says “great teamwork” and the “what didn’t” where everyone deflects. Or people are scared to speak honestly because the manager is listening for ammunition in the next one-on-one. Or retros happen but the team never actually tries the improvements they identify, so by the next retro nobody bothers suggesting anything. Or the whole thing becomes a venting session with no facilitation, so the loudest person’s complaints become the story without anyone actually solving anything.
The thread through all of this: the ceremonies only work when they’re designed for honest conversation and actual improvement. The moment they become performance theater—a way to prove you’re Agile, a way to manage from a distance, a way to check a box—they become dead weight.
If your stand-ups are thirty minutes and everyone’s reading their email, that’s a sign. If your retros identify the same problems sprint after sprint and nothing changes, that’s a sign. If planning takes half the sprint to recover from because nobody was actually clear on what they committed to, that’s a sign.
The good news is that these are fixable. But it takes someone brave enough to say, “This ceremony isn’t working. Let’s change it.” And most teams don’t.