At a healthcare SaaS provider, the team had Scrum-shaped meetings on the calendar, but delivery was still slow. Stories were too large, too vague, and too dependent on a product culture that treated partially delivered value as no value at all. Unless the entire imagined feature was ready to ship, the work might as well not exist.
That created churn. A team would start a large feature, make partial progress, and then pivot when a louder customer wanted something else. Nothing was small enough to ship, learn from, and adjust. The ceremonies existed, but the feedback loops were weak.
That is the difference between doing Scrum and understanding Scrum.
Scrum is not the calendar or the ceremonies. Scrum is a system for turning learning into action quickly enough that the team can still do something useful with it.
Teams fall into the same trap with both Scrum and DORA metrics. They copy the visible practice, track the visible metric, and assume the result will appear because the surface area looks correct. The practice is not the principle, and the ceremony is not the result.
Refinement Changed First
The biggest improvement did not start in sprint planning. It started before planning, with the quality of the work entering the system.
At the healthcare SaaS provider, refinement was slow because the stories were oversized and underspecified. The team could spend an hour discussing three stories because each one contained too many hidden decisions. The work had to be discovered in the meeting because it had not been shaped before the meeting.
The fix was not more ceremony. It was better preparation and smaller slices of value. We introduced MVP thinking, broke large features into shippable pieces, and looked for slices that could reach customers early enough to produce feedback. Once that operating model settled in, refinement moved from roughly three stories in an hour to 13 to 15.
That changed sprint planning. Planning stopped being a negotiation over who had time left and became a commitment to work the team already understood. By the time the practice matured, planning for a two-week sprint averaged about 20 minutes because the work was ready, not because the team had become careless.
Under my direction, that team shipped 63 releases in 52 weeks and delivered a major reporting dashboard incrementally instead of waiting for one giant feature drop. Scrum did not make the team faster by magic. Better feedback loops made the work smaller, clearer, and easier to finish.
Standup Is Coordination, Not Roll Call
The daily standup is where many teams reveal the truth. If everyone takes a turn reporting to the manager, you do not have a coordination meeting. You have a daily status ritual.
A useful standup asks a different question: what is in the way of the sprint goal today? That changes the shape of the conversation. The team listens for dependency conflicts, blocked work, duplicated effort, and decisions that need to happen now instead of next week.
At the healthcare SaaS provider, we eventually moved Tuesday and Thursday standups async. Developers posted their updates in the main chat channel. I later brought the same practice to a financial services SaaS provider once the team had the rhythm and trust to use it well.
The purpose was to share the information, not perform the ceremony. If nobody adjusts after standup, the standup is not doing its job.
Review Is Where Software Meets Reality
The sprint review is not a developer showcase. It is not an internal demo where the team shows each other what they already know.
The review exists because software does not create value until it touches reality. Stakeholders need to see working software, react to it, question it, and help shape what comes next. If the people who can validate the work are absent, distracted, or treated as passive spectators, the loop does not close.
This is where the healthcare SaaS dashboard work changed. Smaller releases meant customers and internal stakeholders could react to real pieces of the product instead of waiting for one giant unveiling. Feedback arrived while the work was still easy enough to shape.
At a financial services SaaS provider, I saw the other version of the same principle. My sprint demos regularly drew more than 30 people, including executives and members of other teams. The format worked well enough that other Scrum masters adopted it.
That did not happen because the ceremony was mandatory. It happened because the review created useful visibility, which is review doing its job.
Retrospective Is an Accountability Mechanism
A retrospective is not useful because people talked. It is useful because the team identified something worth changing and then changed it.
If the same three issues appear every retro, the ceremony is teaching the team the wrong lesson. Communication, documentation, and that recurring technical problem become background noise. People learn that improvement conversations are allowed, but improvement itself is optional.
The first question in a retrospective should be simple: what happened to the thing we said we would change last time? If nobody knows, the retro is theater.
Planning Is Commitment to Understood Work
Sprint planning breaks down when it becomes a negotiation over points instead of a commitment to understood work. Stakeholders ask for more. The team pushes back. Everyone settles on a number that looks responsible enough to put in Jira.
Planning should force clarity: what are we actually building, what does done mean, what assumptions are we carrying, what can we slice smaller, and what would let us learn sooner?
The answer is not always “make the story tiny.” The answer is to make the commitment honest. A team cannot credibly commit to work it does not understand.
The Manager’s Role
The ceremony-without-principle pattern almost always has a management component. Teams notice what leaders reward. If leaders reward status, standup becomes status. If leaders reward impressive demos, reviews become theater. If leaders ignore retro action items, retros become complaint sessions. If leaders pressure teams into commitments before the work is understood, planning becomes fiction.
Managers do not have to run every Scrum ceremony. But they are responsible for the conditions around those ceremonies. They are also responsible for making sure the team does not confuse pageantry with progress.
Whether stakeholders show up, action items get support, the team can say “we do not understand this yet” without being treated as difficult, and the product owner can accept a smaller release because the learning is valuable tells you more about Scrum maturity than the meeting names on the calendar.
The Honest Assessment
Most teams do not need a new process. They need to understand the one they already claim to be using. The ceremonies are mechanisms for generating feedback, surfacing problems, creating accountability, and helping the team course-correct before too much time has been spent building the wrong thing.
If the ceremony does not close a feedback loop, it is theater. It may be well-attended theater. It may be well-facilitated theater. It may look exactly like the process guide says it should look.
It is still theater. Pick one ceremony, name the feedback loop it is supposed to close, and run it as if that feedback actually matters. That is where Scrum starts becoming real again.
Receipts
- Healthcare SaaS provider: Refinement improved from roughly three stories per hour to 13 to 15 once work was sliced smaller, prepared earlier, and treated as shippable increments instead of giant feature bundles.
- Sprint planning: Planning for a two-week sprint averaged about 20 minutes after the work was shaped before the meeting.
- Release cadence: Under my direction, the team shipped 63 releases in 52 weeks and delivered a major reporting dashboard incrementally.
- Standup practice: Tuesday and Thursday standups moved async once the team had enough trust and rhythm to use written updates effectively.
- Review practice: At a financial services SaaS provider, sprint demos regularly drew more than 30 people, including executives and members of other teams, because the review created useful visibility.