Daily Scrum without the status-meeting trap

Many teams hold a daily meeting every morning that they would not miss, and that nobody needs. People stand in a circle, take turns reciting what they did yesterday, and wait for it to be over. Everything that is wrong with it fits in one observation: it is addressed to the person who is listening hardest, who is usually not a Developer.

What the Guide actually says

The Scrum Guide's description is short. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. Its purpose is "to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary." It is held at the same time and place every working day of the Sprint, to keep things simple.

A few details carry more weight than they appear to:

• It belongs to the Developers. If the Product Owner or Scrum Master are working on items in the Sprint Backlog, they take part as Developers. Otherwise they don't need to be there, and the Guide says the Scrum Master makes sure the event happens and stays within its timebox, not that they chair it.
• The structure is theirs to choose. The Developers can use whatever structure and techniques they want, as long as the Daily Scrum focuses on progress towards the Sprint Goal and produces an actionable plan for the next day of work.
• It is about the goal. Not about each person's activity. The question isn't "what did you do?" but "are we on track to achieve what we said we would, and if not, what changes today?"

The three questions are gone

Older versions of the Guide offered three questions as the way to run it: what did I do yesterday, what will I do today, and is anything in my way. The revisions page for the 2020 edition lists their removal among the changes, part of making the framework less prescriptive, and the format is now left to the Developers. Many teams kept the questions, and that's allowed. The point is that the Guide no longer asks for them, so you can't say Scrum requires them.

This matters because the three questions, used mechanically, are the engine of the status meeting. They point each person at their own work, and the listeners nod. Nobody asks whether the sprint is on track, because the format never asks.

How a Daily Scrum goes wrong

It becomes a report to a manager. If somebody outside the Developers is the audience, people speak to them. The answers get longer, safer and less honest. A good test is to ask who the Developers would stop talking to, or change what they said for, if that person left the room.

It becomes a problem-solving session. Someone mentions a blocker, two people dive into the technical details, and the other six look at their phones. The event has a 15-minute box and a clear purpose, and a design discussion belongs after it, with the people it concerns.

It has no link to the goal. If nobody mentions the Sprint Goal for a week, the event is inspecting nothing. You can tell a Daily Scrum is a status meeting when you could run it just as well without knowing what the Sprint is for.

It runs long, or it starts late. A 15-minute box that regularly takes 30 minutes is telling you something: either the team is solving problems in it, or the Sprint Backlog is too tangled to describe quickly. The cure is rarely a stricter timer.

It is the only time anyone talks. The Guide's own description is that the event improves communication and surfaces impediments, and that it can reduce the need for other meetings. A team that waits for 9.30 to raise a problem it found at 9.35 yesterday is using the event as a place to wait.

Formats that keep it about the work

None of these is required, and the Developers are free to choose, change or ignore them. They are only ways to keep the conversation pointed at the goal.

1. Walk the board from the right. Start with the items closest to done and ask what would finish them, then work leftwards. That puts attention on finishing work, not starting it.
2. Start with the goal. Read the Sprint Goal aloud, then ask what moved the team towards it since yesterday and what threatens it today.
3. Plan the day. Finish by writing down who is working with whom on which items today. The Guide asks for an actionable plan for the next day of work, and this is it.
4. A parking lot. When a conversation grows, note who needs to be in it and move on. The follow-up happens straight after, and only for the people concerned.

Who should be in the room

The Guide's answer is simple: the Developers. A Product Owner or Scrum Master who is working on items in the Sprint Backlog joins as a Developer. Everyone else, including managers and stakeholders, is welcome to listen in some teams and not in others, and the test is the one above: does their presence change what the Developers say? If it does, the event has stopped being for the Developers, whatever the calendar invitation says.

The Scrum Master's part is quieter than people expect. They make sure the event takes place and stays inside fifteen minutes, and they coach the team towards a version of it that works. They don't need to run it, and a team that cannot hold the event without them has not yet made it its own.

Remote teams

Everything above applies on a video call, with one extra hazard: it is easier to read out a list when nobody can see anyone's face. A shared board on screen and a rule that the board is what you talk about, not the speaker's last twenty-four hours, helps a lot.

Where to practise

Running a Daily Scrum well is a facilitation skill, and facilitation can only be learned by doing it, ideally where a blocker is waiting to be mishandled.