November 2025 8 min read Case Study
Every morning, in offices and on video calls across the world, teams gather for fifteen minutes to answer three questions. Most of them are going through the motions. Some of them know it. Almost none of them talk about it.
The Hook: The Meeting Nobody Cancelled
The Daily Standup is the most universally adopted Scrum ceremony. It is also the one most universally performed incorrectly. In twenty years of enterprise Agile work, I have attended hundreds of them. I can count the genuinely effective ones on two hands.
That is not an exaggeration. It is a diagnosis.
The Daily Scrum – to use its correct name from the Scrum Guide – was designed as a planning event. Fifteen minutes, for the Developers, to inspect progress toward the Sprint Goal and adapt the Sprint Backlog for the next twenty-four hours. It is not a status report. It is not a progress update for the Scrum Master. It is not a management briefing. It is a team planning event.
What it has become, in most organisations, is a status meeting with standing room only.
The Reality: Three Acts of the Daily Theater
Act One: The Recitation
The scene is familiar. Nine people on a video call or standing awkwardly around a board. The Scrum Master – or sometimes a self-appointed facilitator, or sometimes whoever speaks first – kicks things off. One by one, each team member answers the three questions:
- What did I do yesterday?
- What will I do today?
- Any blockers?
Each person looks at their Jira board while speaking. Each person reports to the room in general – or more specifically, to the Scrum Master, who is nodding and occasionally typing. Nobody is listening to anyone else. They are waiting for their turn. When the last person finishes, everyone says “thanks” and leaves. The whole thing takes twenty-two minutes because one developer goes into detail about a technical problem that is only relevant to two of the nine people present.
This is not a Daily Scrum. This is a roll call.
Act Two: The Manager’s Briefing
A variation on the above, with one significant difference: the manager is present. Not because the Scrum Guide recommends it – it does not. But because the manager wants to know what is happening, and the Daily Standup is the most efficient place to find out.
The effect on team behaviour is immediate and consistent. People report more carefully. Blockers that might reflect poorly on the team are described in more positive language. Progress is framed optimistically. The honest “I’m stuck and I don’t know why” becomes “I’m working through some complexity, should have an update tomorrow.”
The manager gets a daily briefing. The team loses the one forum where honest assessment of their situation was supposed to happen.
If your manager attends your Daily Standup: Ask why. If the answer is “to stay informed” or “to help with blockers” – those are warning signs, not reassurances. A manager who needs to attend daily standups to stay informed has a trust problem. A manager who attends to help with blockers is doing the Scrum Master’s job, which raises a different question entirely.
Act Three: The Blocker That Never Gets Resolved
The most tragicomic act of the Daily Theater. Someone raises a blocker. The Scrum Master notes it. The team moves on. Tomorrow, the same person raises the same blocker. The Scrum Master notes it again. This continues for a week. Sometimes two. The blocker is resolved eventually – either by the team working around it, by someone outside the team noticing and fixing it, or by the sprint ending and the issue carrying forward.
The Daily Standup has identified the blocker every day. It has done nothing to resolve it.
This is the fundamental confusion at the heart of most Daily Standups: they have become reporting mechanisms rather than coordination mechanisms. Reporting that a problem exists is not the same as solving it. The Daily Scrum was designed to trigger action – to give the team the information they need to adapt their plan for the next twenty-four hours. When it becomes a forum for reporting status without triggering adaptation, it has failed at its core purpose.
The Checksum: What the Scrum Guide Actually Says
The 2020 Scrum Guide describes the Daily Scrum in clear terms. Some elements worth highlighting:
| What the Scrum Guide Says | What Most Teams Do |
|---|---|
| 15-minute time-box | Runs 20-30 minutes regularly |
| For the Developers | Attended by Scrum Master, manager, sometimes stakeholders |
| Inspect progress toward Sprint Goal | Report on individual task status |
| Adapt Sprint Backlog as needed | No backlog changes made during or after standup |
| Three questions are one possible format, not required | Three questions treated as mandatory ritual |
| Promotes self-management | Reinforces reporting to the Scrum Master |
That last point in the Scrum Guide is worth emphasising: the three questions – what did I do yesterday, what will I do today, any blockers – are described as one possible format, not as a requirement. The Scrum Guide explicitly states that Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan.
Most teams do not know this. They treat the three questions as Scrum law. The three questions have become the ceremony. The Sprint Goal – which is the actual point – is frequently an afterthought.
“The Daily Standup should be the most useful fifteen minutes of a developer’s day. In most organisations, it is the most predictable waste of it.” Markus – agile-checksum.com
Real-World Examples: Case Studies From the Field
The Twenty-Person Standup
A large telecoms organisation had a daily standup for their product programme. Twenty-three people attended. Each answered the three questions. Average duration: forty-five minutes. When I asked the team what their Sprint Goal was, seven of the twenty-three could answer correctly. The other sixteen gave me a description of their individual tasks.
The standup had grown organically from an original team of eight to a programme-level coordination meeting over eighteen months. Nobody had made a conscious decision to expand it. It had simply grown because adding people to an existing meeting is easier than creating a new one. Each addition had made the meeting slightly less useful and slightly longer. Nobody had cancelled anyone’s invitation because that would have been awkward.
When I recommended reducing it to the core team of eight and creating a separate, optional programme sync for dependency management, the response from senior management was: “But then how will we know what everyone is doing?” That question – and the assumption behind it – was the real problem.
The Standup With No Sprint Goal
A product team I worked with had a daily standup that ran efficiently, stayed within fifteen minutes, and involved genuine conversation rather than recitation. By most observable measures, it was a good standup. There was one problem: the team had no Sprint Goal. Each sprint was a collection of unrelated backlog items. There was no single objective to inspect progress toward.
Without a Sprint Goal, the Daily Scrum loses its primary purpose. You cannot inspect progress toward an objective that does not exist. The team was coordinating their individual tasks – which is not nothing – but they were not doing what the Daily Scrum was designed to do. They were having a well-run meeting about the wrong thing.
The Blocker That Lasted Three Sprints
A development team had a dependency on an external API that was not yet available. This was raised as a blocker in the daily standup. Every day for eleven weeks. The Scrum Master noted it. The Product Owner was aware of it. The external team responsible for the API was aware of it. Nobody with the authority to escalate the dependency and force a resolution was attending the standup or reading the impediment log.
The blocker was eventually resolved when a senior developer mentioned it casually to a director in a corridor conversation. The director made one phone call. The API was available within a week.
Eleven weeks of daily standup reports. One corridor conversation. The lesson is not that corridor conversations are more effective than standups. The lesson is that identifying a blocker is not the same as having a plan to resolve it – and the Daily Standup, as practiced, had conflated the two.
What a Genuine Daily Scrum Looks Like
In the teams where I have seen the Daily Scrum work as intended, it has several consistent characteristics.
- It starts with the Sprint Goal – someone reads it aloud, or it is visible to everyone. The conversation begins with “are we on track to achieve this?” rather than “what did everyone do yesterday?”
- It surfaces real problems – because the team trusts each other enough to say “I’m blocked and I need help” rather than “I’m working through some complexity.”
- It ends with a plan, not a report – the team leaves knowing who is doing what for the next twenty-four hours, and any backlog adaptations have been agreed.
- Blockers trigger immediate action – not a note in the impediment log. Someone owns the resolution before the standup ends.
- Managers are not present – or if they are, they are there to observe and help, not to receive a briefing.
A simple experiment: At your next standup, start by reading the Sprint Goal aloud and asking “are we on track?” See what happens. If the team can answer confidently and specifically, your standup is probably working. If people look uncertain, check their boards, or give vague answers – you have found the problem. The Sprint Goal is the point. Everything else is context.
The Takeaway: Fix the Purpose, Not the Format
Most attempts to fix broken Daily Standups focus on the format. Change the three questions. Try walking the board instead. Do it asynchronously. Stand in a circle. Use a talking token. These interventions occasionally help. They do not address the underlying problem.
The underlying problem, in almost every case, is one of two things: either the team has no clear Sprint Goal to orient around, or the standup has become a reporting mechanism for people outside the team rather than a coordination mechanism for the team itself.
Fix the Sprint Goal problem and the standup becomes purposeful. Fix the audience problem and the standup becomes honest. Fix both and you might – might – have a Daily Scrum that resembles what the Scrum Guide describes.
Run the checksum on your Daily Standup:
- Can every person in the standup state the Sprint Goal from memory, right now, without looking it up?
- When was the last time the standup resulted in an actual change to the Sprint Backlog?
- Would the team behave differently in the standup if the manager was not present?
If the answer to question three is yes – you do not have a Daily Scrum problem. You have a psychological safety problem. And no standup format will fix that.
“The Daily Standup is a mirror. What you see in it is a reflection of your team’s actual relationship with its work, its goals, and each other. Most teams do not like what they see. So they look at the board instead.” Markus – agile-checksum.com
Glossary Terms Used in This Article
- Daily Standup – A 15-minute daily Scrum event for the Developers to inspect progress and adapt the Sprint Backlog.
- Sprint – A fixed time-box of 1-4 weeks in which a Scrum team delivers a potentially releasable increment.
- Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team.
- Psychological Safety – The shared belief that it is safe to take interpersonal risks within a team.
- Backlog – An ordered list of work items representing everything a team might work on.
No Fluff. Just Real Agile.
Straight to your inbox. No buzz, no spam.