Christian Neiderstam ← All artifacts
Scrum event · it belongs to the Developers

Daily Scrum

Three transcripts from one team, six days apart. Same fifteen minutes, same two developers, entirely different meetings.

Every day of a Sprint · Chapter 13 · Jump to the first transcript

The Daily Scrum is how a Sprint gets steered day to day. It sits outside the chain. WHY VISION GOAL WHAT EPICS STORIES DONE

The Daily Scrum belongs to the Developers. The Scrum Master makes sure it happens and stays inside the timebox.

The Scrum Master does not run it.

That sentence is easy to agree with and remarkably hard to obey. What follows is what it looks like when you don't, and then what it looks like when you stop.

The Sprint Goal these three meetings are steering toward

“Enable new BCA members to securely create an account, log in, and establish their initial identity with a display nickname within the app.”

Day 4 — everything goes through the Scrum Master

Day 4 Scrum Master speaks 3 of 5 turns · developer-to-developer: 1
Christian Hans, kicking off with you. How are things progressing toward getting users registered, logged in, and a nickname set?
Hans Yesterday I got the basic registration UI set up and started client-side validation for email. Today I'll finalise the form validations and start structuring the API call to Greta's endpoint. No major blockers, but I need to confirm the error codes her API will return so I can map them to user-friendly messages.
Christian Good point on the error codes. Greta, how's the backend shaping up?
Greta Wrapping up POST /api/register. User creation and password hashing are in. Hit a snag with the database connection pool yesterday but adjusted the configuration and it's stable. Next, unit tests for registration. Hans, I'll send the error codes within the hour.
Christian Excellent collaboration. Greta, well done tackling that database issue. Team, looking at the board and the Sprint Goal, any adjustments to today's plan?

Read that back and say what's wrong with it.

It's friendly. It's on topic. It finishes in twelve minutes. Every question asked was a good question.

And every single word goes through the Scrum Master.

He calls on Hans. Hans answers him. He acknowledges, then calls on Greta. Greta answers him — though watch her slip one sentence sideways to Hans about the error codes, which is the only genuinely useful exchange in the entire meeting, and the only one he didn't cause.

This is the most common Scrum Master mistake there is, and it doesn't feel like a mistake at all.

It feels like facilitation. The team is talking. The meeting is efficient. Nobody's unhappy.

What's actually happening is that two developers are quietly learning that alignment is something the Scrum Master does for them.

It ran like this for four consecutive days.

Day 5 — what changed

One sentence at the start, and then silence.

The intervention
This is your meeting. I'm here to hear about impediments.
Then stop talking. The silence is uncomfortable for about ten seconds and worth every one of them. Fill it, and the team learns that somebody else always will.

Day 8 — the team runs it, and the impediment surfaces

Day 8 Scrum Master speaks 0 of 6 turns · developer-to-developer: continuous
Hans Registration flow is testing end to end now. Today I'm on the login screen. Greta, is the token refresh behaviour settled, or should I build defensively?
Greta Settled as of last night. Fifteen-minute access token, refresh on 401. I'll send the sequence diagram after this.
Hans Then I can finish login today instead of tomorrow. Which means nickname starts a day early.
Greta Good, because I want your input on where the nickname uniqueness check lives. Frontend or backend. Five minutes after this?
Hans Yes.
Greta One thing for you, Christian. The email verification service. Nobody has told us which provider we're using, and registration can't be Done without it.

Same fifteen minutes. Entirely different meeting.

They're planning against each other now instead of reporting upward. Hans re-plans his day inside the meeting based on what Greta just told him. They schedule their own follow-up without asking permission.

And the only thing that comes to the Scrum Master is the one thing he can actually do something about.

That last line is what a Daily Scrum is for. Everything before it was the team managing itself. The impediment surfaced because there was room for it — not because anyone asked a question that went fishing.

What the three meetings show

Day 4Day 5Day 8
Who speaks firstScrum MasterSM once, then silenceDevelopers
SM turns3 of 51 of 60 of 6
Dev-to-dev exchanges1, sideways1 design decisionContinuous
Re-planning in the meetingNoneNoneYes
Impediments raisedNoneNoneOne, to the right person

The developers did not become more capable over four days. The room made space for capability that was already there.

Impediment or problem?

Greta raised two things across those transcripts and only one of them was for the Scrum Master. Telling them apart is most of the job.

ImpedimentSomething blocking the team that the team cannot resolve itself. A missing licence. An unresponsive vendor. A decision belonging to somebody with authority the team doesn't have.
ProblemSomething hard that the team can solve. A failing test. An architecture disagreement. A tricky bug.

Greta's database connection pool was a problem, and she had already solved it by the time she mentioned it. The missing email provider was an impediment, because the decision sat outside the team.

A Scrum Master who solves problems steals learning. A Scrum Master who ignores impediments wastes the team's time.

Get it wrong in either direction and you damage the team.

On the structure

The “yesterday / today / blockers” round is not required by Scrum. It was removed from the Guide in 2020, precisely because it turns the event into a reporting ritual.

Developers may use any structure they like, as long as it focuses on progress toward the Sprint Goal. The Day 8 transcript has no structure at all. That is allowed, and it is working.

What happened to the impediment

It reached the Scrum Master on day eight and he did not clear it. Not because he forgot — because chasing a provider decision through procurement felt less urgent than the things in front of him that week.

Surfacing an impediment is not the same as clearing it. What that one cost is in chapter 1, free to read.


Where this sits

The Daily Scrum steers a Sprint between Planning and the Review. The dependency Greta raised had already failed the Definition of Ready before the Sprint started — the Daily Scrum is where it became visible again, with most of the Sprint spent.

Transparency

An artifact board everyone can open

Transparency is one of Scrum's three pillars, alongside inspection and adaptation. Without it the other two have nothing to work on. It's also what makes a why-to-done chain worth building.

Every outcome of that chain should be readable by anyone involved in the project, formally or informally. Not a folder somebody has to request access to. A board you can open.

That matters most in the later stages. You're four Sprints in, arguing about whether something's in scope. The answer usually sits in a decision made months earlier. And the only useful version of it is the one written down at the time, not the one people remember.

It also means the chain can be inspected. Markets throw curveballs and businesses change their minds. Drivers that were right in January can be wrong by June. Put them somewhere visible, revisit them on a deliberate cadence, and the chain adapts. Leave them in a document nobody reopens and it quietly stops being true.

The stakeholders own the top of that chain — the drivers, the vision and the Product Goal — so they're the ones who inspect and adapt it. Not the Scrum Master, and not the team. Your job is to put the question in front of them on a cadence they've agreed to, and to make sure what they decide gets written where everyone can see it.

Beauty Spot's board is public, and free to read whether you buy the book or not.

Open the card on Trello →

This is one of thirty-one artifacts from Worth Building with Scrum: From Why to Done — the chain from a business driver to a line of finished code, worked through one team's four Sprints. About the book · read chapter 1 free.