The value stream

The Daily Scrum

The Daily Scrum is Scrum's best-known event, and also the one most often misused. Many teams turn it into a round in which each person reports on the day before. The pattern describes something else: fifteen minutes during which the Developers remake their plan for reaching the Sprint Goal. This article explains what the pattern asks for, where the "three questions" came from and why the Scrum Guide removed them in 2020.

A round that helps nobody

Quarter past nine. A team is developing the booking software for a network of public libraries. The six developers stand in a semicircle facing Karim, their Scrum Master, whose job is to help the team apply Scrum well. He holds the task list.

"Yesterday I worked on the renewal screen," says Léa, looking at Karim. "Today I'm carrying on. No blockers."

"Yesterday I had meetings, then I made progress on the export. Today I'm carrying on with the export," Thomas follows.

Karim checks off the lines. When her turn comes, Inès mentions that she has been waiting two days for access to the test database. Karim notes it down, and nobody reacts. The meeting lasts twenty-five minutes. On his way back to his desk, Thomas discovers by chance that Léa has been changing the same module as him since the day before.

Everyone has spoken and the list is up to date, but nothing has been decided. The team's plan is the same as before the meeting, Inès is still blocked, and two people are getting in each other's way without knowing it. Everyone addressed Karim rather than their colleagues. This is the scene the Daily Scrum pattern seeks to avoid. It appears in A Scrum Book (2019) by Jeff Sutherland, James Coplien and their co-authors, where each pattern sets out a recurring problem, the forces at play and a solution proven by practitioners.

A plan out of date by the next day

The pattern applies once the team has begun its Sprint, the fixed-length work period that sets Scrum's rhythm. The team has a Sprint Goal and a Sprint Backlog (the Developers' work plan), both produced at Sprint Planning, the meeting that opens the Sprint. The authors recall the words of the Prussian field marshal Helmuth von Moltke: "no plan of operations extends with any certainty beyond the first contact with the main hostile force." The plan drawn up at the start of the Sprint ages in the same way, and the pattern gives the reasons.

In complex work, tasks change constantly. Hidden tasks appear, a requirement turns out to have been misunderstood, two developers depend on each other, an obstacle blocks someone or a colleague is absent.
The order of tasks matters. The authors calculate that a hundred tasks can be arranged in about 9 × 10¹⁵⁷ ways, very few of which make the work flow smoothly. Yesterday's good order is no longer today's.
Replanning too often wastes time and stifles the Developers. Replanning too rarely lets blockages drag on and keeps alive a plan that no longer describes reality.
A person on their own decides quickly, but a team decision requires the presence of everyone it affects. Someone with a problem to put to the group does not easily find the moment to do so.

Fifteen minutes to replan

The pattern's solution is to "have a short event every day to replan the Sprint, to optimize the chances first of meeting the Sprint Goal and second of completing all Sprint Backlog Items." The order of these two aims matters, since the goal comes before the list. The meeting deals with the day's work, without losing sight of the rest of the Sprint.

Several rules go with this solution. The length is limited to fifteen minutes, and the team disciplines itself to keep to it. Many teams remain standing as a reminder. All the Developers are present, and someone who is absent does not send a stand-in. The meeting is for deciding, not for solving problems: when an obstacle is raised, the people concerned agree to meet afterwards, without holding up the others, and report back the next day. If the team regularly goes over the quarter of an hour, the authors see it as the sign of a defect to be corrected in its way of working.

The result is an updated Sprint Backlog. The boards and charts on the wall are updated too, but the pattern specifies that this information is a by-product. It puts it bluntly: "the Daily Scrum is a replanning meeting and not a status meeting." The underlying question is whether the team will reach its goal.

The next day, done differently. The library team changes its approach. Karim stays in the background. The Developers stand in front of their board and start from the Sprint Goal: "readers can renew a loan online".

"We have four days left, and renewal doesn't work end to end yet," says Léa. "What's standing between us and that?"

"Access to the test database," replies Inès. "Without it, I can't check the renewal rules."

"I'll deal with it this morning with the operations team," says Thomas. "The export can wait, it doesn't serve the goal."

"As soon as the access is there, I'll take the rules with Inès," Léa goes on. "Meanwhile, I'll finish the screen."

The meeting lasted seven minutes. The team made three decisions: the export is on hold, Thomas clears the blockage, and Léa will work with Inès.

The authors attribute other effects to the Daily Scrum: obstacles become visible every day, opportunities to help one another appear, and the daily ritual strengthens the team's identity. They also tell its origin. In the early 1990s James Coplien had studied the team at Borland that was developing the Quattro Pro for Windows spreadsheet, and which met every day. The first Scrum team took up this practice in February 1994. According to the account given in the pattern, in March it took on the same amount of work as the previous month and finished it in the first week. This account concerns a single team and comes from the authors themselves. It is not a measurement.

The three questions

To replan, you need to know where you stand. The pattern presents as a widespread technique the practice of each developer answering three questions: what they did yesterday that helped the team reach the Sprint Goal, what they will do today for the same purpose, and what obstacles they see in the way of that goal. In the book, these questions serve to prepare the decision.

The history of the Scrum Guide, written by Ken Schwaber and Jeff Sutherland, shows these questions gradually receding. The first editions made them the content of the meeting. The 2013 revision reworded them around the Sprint Goal, stressing that the Daily Scrum was too often seen as a status meeting. The 2017 edition gave them only as one possible example. The 2020 edition removed them, as part of a general lightening of prescriptions. It lets the Developers "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 for the next day of work."

This withdrawal makes sense if you reread the first scene. Asked of each person in turn, the three questions produce a series of individual reports, addressed to whoever is running the meeting. They remain usable if the team uses them to decide. Another common practice is to go through the board item by item, starting with those closest to being done, and to ask what is needed to finish each one.

The Developers' meeting

The pattern is clear on this point: the Daily Scrum is the Developers' meeting. Other people may attend if the Developers invite them, but only the Developers take an active part. The rule also applies to the Product Owner, the person accountable for the value of the product. The authors acknowledge that transparency argues for an open meeting, while observing that the mere presence of an outsider changes what is said.

The case of the Scrum Master is dealt with separately. The Scrum Master may attend the meeting, especially in the early days, to help the team keep to time. But the Developers often start treating the Scrum Master as a boss, and the meeting slides toward status reporting. The ScrumMaster Incognito pattern describes this problem: the Developers address the Scrum Master, wait for approval before acting and no longer behave as a team. The solution is for the Scrum Master to make sure the team takes ownership of the meeting. The Scrum Master can stand behind the person speaking to them, quietly leave the room or explain why this ownership matters.

The 2020 Scrum Guide goes in the same direction, with a nuance. It defines the Daily Scrum as "a 15-minute event for the Developers of the Scrum Team" (the book still writes "Development Team"), held at the same time and place every working day. It adds that if the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they take part as Developers.

Beyond software, ten minutes in front of the bed board

A hospital medical ward (fictitious example). In a ward of twenty-eight beds, the team has set itself a goal for the two-week Sprint: no patient coming from the ER should wait for a bed after noon. Every morning at 9 o'clock, the nurses, the healthcare assistants, the junior doctor and the social worker meet for ten minutes, standing, in front of the bed board. The night handover took place at 7 o'clock, and nobody repeats it.

The team looks at the four discharges planned for the day. Two are blocked, one by a missing scan report, the other by an ambulance that has not been booked. The junior doctor will call radiology before 10 o'clock. A healthcare assistant books the ambulance. The social worker will first see the family of the patient in bed 12, whose discharge is planned for the next day. At ten past nine, everyone knows what is changing in their morning.

This example shows the features of the pattern: a common goal, a review focused on what is preventing the team from reaching it, and decisions made by the people who do the work. The problems themselves are sorted out after the meeting.

Limits and pitfalls

Drifting into a reporting meeting is the main pitfall. It can be recognized by a few signs: all eyes turn to one person, sentences begin with "yesterday I", a manager asks the questions, and nobody changes their plan on the way out. An activity report reassures whoever receives it, but it does not help the team reach its goal.

Other failings are common. Some teams solve problems during the meeting, and the quarter of an hour becomes three quarters of an hour. Others wait until the next morning to report a blockage that arose at 10 o'clock, whereas the 2020 Scrum Guide points out that the Daily Scrum is not the only time the Developers are allowed to adjust their plan. When tasks each last several days, nothing changes from one morning to the next and the meeting goes around in circles, as the Small Items pattern notes.

Finally, the authors point out a widespread confusion, which consists of believing that a team "does Scrum" because it holds a stand-up meeting every morning. As they put it, "kicking a football around in a park can look a lot like playing football, but it isn't football."

On the effectiveness of the practice, the available research calls for nuance. Viktoria Stray, Dag Sjøberg and Tore Dybå studied twelve development teams in three companies, drawing on sixty interviews and seventy-nine observed meetings (Journal of Systems and Software, 2016). Participants valued above all the sharing of information and the chance to discuss problems and solve them, which qualifies the pattern's rule on this point. They criticized the meeting for serving as a report to the manager, for being too frequent and for lasting too long. This qualitative study does not measure a gain in productivity. It does indicate, however, that reporting to the manager is one of the main reasons the meeting is rejected. The article Criticism and the state of the evidence places these results in a wider context.