A Scrum Master I worked with kept a beautiful calendar. Every event color-coded, every invite on time, the board green by Friday. When I asked which of those events had changed a single decision last sprint, the room went quiet. That silence is one of the most common problems in Scrum, and almost nobody names it out loud.
It is easy to believe that if the events are on the calendar and people show up, the team is doing Scrum. Attendance is not value, though. Most teams keep running the format long after the function died.
Nobody on your team will admit the standup is dead, because saying so feels like admitting they wasted a year of mornings. So the format limps along, everyone calls it agile, and the calendar quietly fills with sessions that no longer produce anything.
What follows are the recurring sessions I see decay most often. For each one, here is what it looks like on autopilot, what it was actually for, and one move to restart it. None of these require a process overhaul. They require you to remember the point.
1. The Daily Scrum that became a status report
On autopilot, it is a round-robin. Each person recites what they did yesterday and will do today, the manager nods, and two developers quietly answer Slack on a second screen. Information flows one direction and nobody decides anything.
That was never the point. The Daily Scrum is the developers' own planning huddle, a quick inspection of progress toward the Sprint Goal so they can adapt the plan for the day.
Restart it by dropping the round-robin. Open with one question instead: what is in our way of meeting the Sprint Goal today? Walk the board from the work nearest done, and talk about the work, not the worker. A team I coached cut a fifteen-minute report down to four minutes of actual replanning that way.
2. Sprint Planning that became a ticket assignment session
On autopilot, the Product Owner reads tickets aloud, names get attached, and someone does capacity math in a corner. There is a full sprint of work and no shared reason for any of it.
Sprint Planning is supposed to be a working session where the team crafts a Sprint Goal and a plan to meet it, then pulls the work. The Scrum Guide is clear that the goal comes first, not the task list.
Restart it by refusing to touch a single ticket until the team can say the Sprint Goal in one sentence. Pick the outcome you are betting on, then select the smallest set of work that serves it. Assignment can wait; commitment to a goal cannot.
3. The Sprint Review that became a demo
On autopilot, it is a polished show-and-tell. The team presents, stakeholders clap or stay silent, and everyone leaves without a single decision about what to build next. Over time the stakeholders stop showing up at all.
A review is meant to be a working session where stakeholders inspect the Increment and the team adapts the Product Backlog together. A demo broadcasts; a review decides. That distinction is the whole game, and I unpacked it in detail in this piece on sprint review versus demo.
Restart it by asking one question after each item: given what you just saw, what should we do next? You are collecting decisions, not applause. If your stakeholders have already drifted away, there is a way to bring them back, and it starts with giving them something to decide.
4. The Retrospective that became a feelings circle
On autopilot, everyone vents, the mood lifts for an hour, and nothing is different by the next sprint. It feels supportive, which is exactly why it survives so long without producing change.
The retrospective exists to inspect how the work went and to commit to at least one improvement the team will actually try. The Scrum Guide treats that next improvement as the output, not the conversation itself.
Restart it by ending every retro with one improvement that enters the next Sprint Backlog, with an owner and a date. Then open the following retro by checking whether last time's change actually happened. A retro that never carries an action forward is theater with snacks.
5. Backlog Refinement that became group estimation
On autopilot, the team assigns numbers to items nobody fully understands, then argues about whether something is a five or an eight. The estimate becomes the goal, and the understanding never arrives.
Refinement is an ongoing activity rather than a formal event, which is exactly why it drifts so easily. Its real job is to clarify and slice work until each item is small and genuinely understood.
Restart it by refusing to estimate what you cannot explain. If an item cannot be described in two plain sentences, that is the signal to slice it smaller or write down the open question and bring back an answer. Smaller, well-understood slices give you faster feedback, and faster feedback is the entire reason to refine in the first place.
6. PI Planning that became a calendar exercise
If you scale with a framework like SAFe, you may run PI Planning, and it decays in a recognizable way. On autopilot, teams fill a spreadsheet of dates and commitments, nobody negotiates across teams, and the real dependencies surface later in production.
PI Planning is not a Scrum event, but the intent behind it is sound: align teams on a shared set of objectives and surface dependencies and risks together, in the open. The plan is a byproduct; the alignment is the product.
Restart it by judging the session on the dependencies you surfaced and the risks you chose to manage, not on how full the calendar looks at the end. If you do not scale, you can skip this one entirely, and you should not feel guilty about it.
A few ways teams make this worse
The first trap is blaming people instead of formats. The session decayed, not the person who scheduled it, and the moment this feels like a performance review the honesty disappears.
The second trap is deleting the event instead of restoring it. The work still has to happen somewhere, so if you cut the session without moving the collaboration, you have only hidden the problem. This is why "no process" agile tends to fail the teams that try it, a pattern worth pruning carefully rather than abandoning.
The third trap is chasing more structure or less structure as the goal. The goal is never the amount of process; it is whether the session produces a decision, a learning, or an action. And yes, the event everyone complains about is usually the one they will fight hardest to keep, because a full calendar feels safer than the silence.
Do this Monday morning
Pick the one event your team dreads the most. Before its next occurrence, state the event's purpose as a question and open with that, instead of the usual agenda. For the Daily Scrum, that question is "what is blocking the Sprint Goal today?" For the review, it is "what should we do next, given what we just saw?"
If the room cannot answer in two minutes, you have found your first redesign candidate. Do not cut it on the spot. Write down what you heard, bring it to the retrospective, and decide together. One restored event is worth more than a calendar full of habits.
If your team wants a hand restoring these events without a heavy reset, that is a lot of what we do in our coaching work, and it is the backbone of the Certified ScrumMaster course.