The fifteen-minute Daily Scrum: why 15, and what to do at 16

Fifteen minutes is short enough to feel arbitrary, and many teams treat it as a suggestion. The first overrun is five minutes, and in a month it is twenty-five. At that point the Daily Scrum has become a meeting, with a meeting's habits. The limit was set to stop exactly this, and it is worth understanding what it protects.

What the sources say

The Guide describes the Daily Scrum as a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. The SBOK® Guide agrees on the length: its Daily Standup Meeting is time-boxed to 15 minutes. Both treat the number as fixed. The Guide's maximum durations for the other events vary with the length of the Sprint, and this one does not, because it is a daily event whose job does not change.

The Guide gives the reason in two places. The Daily Scrum improves communication, identifies impediments, promotes quick decision-making and consequently eliminates the need for other meetings. And it is not the only time the Developers adjust their plan: they often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work. So the Daily Scrum is the point of inspection, and detailed problem-solving happens elsewhere.

What fifteen minutes forces

Selectivity. There is no time to say everything, so the team has to say what bears on the Sprint Goal. That is the discipline the Guide intends.

Separation of inspection and discussion. A problem is named in thirty seconds and discussed afterwards by the people it concerns. The rest of the team is not held hostage to a conversation that is not theirs.

Cheapness. An event that costs fifteen minutes can be held every day without anyone resenting it. At forty-five minutes it would be dropped within a month. The Agile Manifesto principle on a sustainable pace is relevant: events that fit comfortably into the day are events that survive.

A prompt to prepare. People who know they have little time think before they speak.

The arithmetic of team size

A rough calculation shows why teams overrun. Fifteen minutes divided among seven Developers is a little over two minutes each, and that assumes no time is spent starting, looking at the board or discussing. If each person speaks for two minutes in a person-by-person format, the meeting is fourteen minutes without a single follow-up question. Add a short discussion and you are at twenty.

Two conclusions follow. First, formats based on turns scale badly with team size. A board-based or goal-first format, where the unit is the work and not the person, does not grow with headcount. See Daily Scrum formats. Second, the Guide's advice to keep the Scrum Team small, typically ten or fewer, has a practical side here: a team of twelve cannot hold a useful Daily Scrum in fifteen minutes, and that is one reason to split it.

A worked example: what to do at minute sixteen

This is an illustrative scene. A team of six is on day five of a ten-day Sprint. At minute twelve, a Developer mentions that the payment service returns a new error code. Two others have seen it. A debate begins about whether to handle it in the existing flow or add a new branch.

At minute fifteen, the Scrum Master, who is attending as a facilitator, says: "We are at time. Who needs to be in this conversation?" Three raise a hand. The others return to the board and close the meeting with the plan for the day. The three stay for ten minutes, agree a design and update the Sprint Backlog with two tasks. A fourth Developer who was not in the room reads the note and is not affected.

Nothing was lost. The meeting ended on time, the plan was complete, and the discussion took place among the people who needed it. The cost of those ten minutes was three people's time and not six.

The pattern has a name in many teams, the parking lot or "after-party". It is practitioner custom and not part of the Guide, but it follows from the Guide's remark about detailed discussions happening throughout the day.

When it keeps overrunning

Occasional overruns are normal. A pattern is information. Common causes and what to try:

• The format is turn-based and the team is large. Change to a board-based format.
• People are solving problems in the meeting. Agree a rule that anything beyond thirty seconds is parked.
• The Sprint Backlog is unclear. If the board does not show the work, people explain it aloud. Improve the board.
• Someone is reporting upward. If a manager is present and the team speaks to them, the event has stopped being for the Developers.
• The Sprint Goal is vague. Without a clear goal, nothing sorts what is relevant. Revisit it.
• The team is too large or too split. Two sub-teams with different goals cannot share a fifteen-minute event.

Do not respond to overruns by extending the box. The Guide's number is not negotiable in the way a team may like, and a longer event makes the underlying problem harder to see.

The first two minutes and the last two

The edges of the event decide whether the middle works. In the first two minutes the team should be looking at the same thing, usually the board and the Sprint Goal, so that the first speaker does not have to set the scene. In the last two, someone says aloud what the plan for the day is: who is working with whom, what is being chased and who will update the Sprint Backlog. This is the actionable plan the Guide asks for, and saying it takes under a minute. Teams that skip it find that the meeting felt useful and changed nothing.

A related habit is to end on the minute. A meeting that stops on time is a small promise kept every day, and teams that keep it find that people arrive prepared and leave without checking the clock.

What the box is not

It is not a target to fill. A Daily Scrum that finishes in eight minutes with a plan for the day is a success. It is not a rule for the whole day, either: the Developers can and should meet as needed outside it. And it is not a licence to skip, since the Guide says that failing to operate any event as prescribed results in lost opportunities to inspect and adapt.

How to practise it

Time your next ten Daily Scrums and note the reason for every overrun. A tally is more persuasive than a feeling. In the simulator you meet a Daily Scrum at step 3.2 where the tasks and blockers compete for a short window, which is a fair picture of the real constraint.