Daily Scrum

There was a time when the only way to ask how far along something was involved a weekly report. Gather it once on Monday and the next picture arrives the following Monday. For the five days in between, a team works without knowing what anyone else is doing.

The gap showed up whenever someone got stuck. On Tuesday an engineer runs out of work because another team hasn't answered a question. The person at the next desk doesn't know, and neither does the manager. It surfaces on Friday as "still waiting" in the report, four days later. Something that would have taken a day to clear eats a week instead.

Duplicated work surfaced late for the same reason. Two people build a similar screen in parallel for most of a week, discover the overlap at review, and one of the two versions gets thrown away.

The daily scrum exists to shrink that gap to a single day, and it does it by turning the flow of information sideways instead of upward. Scrum cuts work into fixed-length cycles called sprints; this is the joint inside a sprint where the team re-aims once a day.

Same time, same place, fifteen minutes, everyone speaks once. Fifteen minutes is a specification rather than a ceiling. Let it stretch and people start arriving late the next day.

Each person covers three things.

1. What finished yesterday — finished, not percentages. Not "the login screen is 70 percent done" but "login screen is done and the review is up."
2. What happens today — sized so it can be checked by tomorrow. "Working on payments" produces the same sentence tomorrow. "Getting the payment failure screen wired up" gives the team something to check against.
3. Where it's stuck — work that can't move because of some outside condition is called a blocked item. Waiting on an answer counts, and so does not having access to something. Work you simply haven't started yet is not a blocker, and the distinction matters because blockers are the only items the session promises to act on that same day.

One rule holds the whole thing together: a blocked item gets named, not solved. Agree on who will look at it afterward and move on. Skip that and a fifteen-minute slot turns into a forty-minute technical discussion while five people who aren't involved stand and wait.

The habit of standing comes from the same place — it is where the alternate name, daily standup, came from. Sitting makes it longer.

Going around the board beats going around the room. Walk the items on the board from the right-hand column and let whoever owns each item speak. Person by person, everybody reports their own slice and stops; item by item, what's at risk in the sprint backlog becomes visible.

The people who attend are the ones doing the work this cycle, which scrum calls the development team. That covers designers and whoever handles testing, not only engineers. It isn't a place to relay news on behalf of absent people, so keep observers to a minimum.

The scrum master helps the session run and clears the blocked items that come out of it, but doesn't own the meeting. Once that seat starts chairing it, people stop talking to each other and start talking to the chair. When a manager does observe, questions wait until afterward. A useful test is whether the team would still hold the session with that seat on vacation; if the answer is no, it has quietly become someone else's meeting.

The hour of the day doesn't matter much as long as it never moves. Near the start of the working day is the most common choice, because whatever gets said can still change how the day goes. Rescheduling it daily costs more time than the meeting.

Past about nine people, fifteen minutes stops being enough for everyone to speak. At twelve people each person gets a little over a minute, and a minute turns the exchange into a recitation. Split into smaller teams at that point and have one person from each meet once more.

Teams spread across time zones or working under remote work often do it in writing. Communication that moves without everyone being online at once is asynchronous communication, and here it looks like everyone posting the same three things to a channel by a set hour. The trade is a record you can search against a reply time measured in hours, so many teams flag blocked items separately and take only those to a short call.

"I've been blocked since yesterday waiting on the API response format. Same state today."

A second-day blocked item, which means someone has to step in before the day ends.

"Let's not settle that here — you two can take it after this."

Protecting the fifteen minutes when a discussion starts to run long.

"The daily isn't a status report, it's where we line up what we're each doing today."

Steering the session back when it drifts into progress reporting for a manager.

At Pagedeck the session runs at 10 a.m. for fifteen minutes. One Tuesday, Theo said he hadn't been able to start the payment integration for two days because the test account still wasn't set up. Under the old weekly rhythm that wouldn't have surfaced until Friday. Sofia, standing right there, said she already had the account. Thirty seconds out of fifteen minutes.

In the same session, Noa mentioned she was posting the pricing screen mockup that day, and Theo answered that he needed it that day to land the screen inside the cycle. That coordination isn't something the meeting produced — it followed from each of them knowing what the other was doing.

The most common misreading is treating it as a status report for a manager. Saying what you did every day has exactly the shape of a report, so the assumption is easy to make. But the audience here is the colleagues running the same cycle alongside you, not a manager. Once it settles into a report, people start speaking in a way that produces an impression of progress, and trouble gets buried. A session built to surface blocked items early becomes the last place they appear. The fix is usually smaller than dropping the session — it is the manager standing back a step, or moving those questions to a one-on-one later in the day.

Using it to solve problems is the other one. A blocker just came up, so fixing it on the spot looks efficient. The discussion usually needs two people, though, and the rest stand and wait. Three sessions of forty minutes instead of fifteen costs the team close to two hours a week, and the next thing said out loud is a proposal to drop the daily entirely. Name the blocker in the session, handle it outside. What gets cleared that way accumulates into material for the retrospective, where the team fixes the process itself.