Daily Scrum formats and how to choose one

A Daily Scrum is the one event a team holds every working day, which makes it the one that wears down fastest. After a few weeks of the same words in the same order, people stop listening. The Guide anticipated this by leaving the format open. What it fixes are the purpose, the length and the outcome. Everything in between is the team's choice, and it is meant to change.

What is fixed and what is free

The purpose of the Daily Scrum, in the Guide's words, is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It is a 15-minute event for the Developers, held at the same time and place every working day. The Developers can select whatever structure and techniques they want, as long as the Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

So two tests apply to any format. Does it keep attention on the Sprint Goal? Does it end with a plan for the next day? A format that does both is acceptable, whatever it looks like.

The SBOK® Guide's Daily Standup is built around three questions about what each person did, what they plan to do and what is in their way. It is a valid format and was the standard for a long time. Under the Guide it is one choice among several.

Six formats

1. The three questions. Each person answers what they did, what they will do and what blocks them. It is simple and quick to learn. Its weakness is that it directs attention to individuals rather than to the goal, and it can drift into a status report to whoever is listening. It suits a new team that needs a structure to begin with.

2. Walk the board by item. Go through the items on the Sprint Backlog, starting nearest to done, and ask what is needed to move each. It focuses on finishing, and it makes stuck work visible. It suits a team with a well-kept board.

3. Goal first. Read the Sprint Goal, then ask whether the team is on track, what changed since yesterday, and what could stop it. Then adjust the plan. It keeps the commitment at the centre, and it is strong when a Sprint Goal is clear and risky.

4. Risk first. Start with the biggest uncertainty or dependency and ask who can reduce it today. It suits a Sprint that depends on something unknown, such as an external system.

5. Pairs and swarms. Each pair or group reports on its piece, and the discussion ends with who is helping whom. It suits teams that work in pairs or mobs, where individuals are not the natural unit.

6. Written and asynchronous. Each person updates the board or a short text note before a set time, and the live part is short and about what needs a conversation. It suits teams across time zones, and works poorly when it replaces the conversation entirely.

The GOV.UK Service Manual's advice on agile working notes the value of a shared visual board for stand-ups, whether on a wall or a digital tool. Formats 2, 3 and 4 all rely on one.

A worked example on one board

This is an illustrative case. A team of five has a Sprint Goal: a customer can reschedule an appointment online. On day six the board shows five items: the reschedule form (in progress), the availability check (in review), the confirmation email (to do), the calendar update (blocked) and the error messages (to do).

With format 1, each person talks in turn. Three give accurate accounts of their own tasks, one says "same as yesterday", and nobody mentions that the blocked calendar update is on the critical path. The meeting runs thirteen minutes and ends without a plan.

With format 2, the team starts at the right of the board. The availability check needs a review: someone offers. The reschedule form needs the check: it will follow. The calendar update is blocked on a third-party account: who can chase it today? The meeting runs ten minutes, and each item has a next step.

With format 3, they read the goal and discuss whether it will be met. They conclude that the calendar update puts the goal at risk and agree that two people will work on a mock of the service so that the rest is testable. The meeting runs twelve minutes.

All three are legal under the Guide. The second and third produce a clearer plan for the next day, which is the outcome the Guide asks for.

How to choose

A short procedure works.

1. Look at what the last three meetings missed. If blocked work was not noticed, try a board-based format. If the goal was not mentioned, try goal first.
2. Pick one and run it for a Sprint. A format needs a few days to feel natural.
3. Review it in the Retrospective. Ask what the format helped and hid.
4. Change it deliberately. Rotate between formats every few Sprints if the team gets bored, or when the nature of the work changes.

The Scrum Master's role is to make sure the event takes place and stays within the timebox, and to coach the Developers toward a version that works for them, as the Guide expects. It is not to choose the format for them.

Things that work in any format

• Start on time and at the same place. The Guide says to hold the event at the same time and place every working day to reduce complexity.
• Look at the board together. A shared view beats memory.
• Leave with names. The plan for the next day should say who is doing what.
• Park the long conversations. Note who needs to talk and do it straight afterwards. The Guide says the Developers often meet throughout the day for more detailed discussions about adapting or re-planning, so the Daily Scrum need not hold them.
• Keep the Product Owner and Scrum Master quiet unless they are working on Sprint items. If they are, they take part as Developers.

Common mistakes

• Letting the format harden into a ritual. If you can predict every sentence, change it.
• Making the Scrum Master the audience. The event is for the Developers.
• Choosing a format to suit a manager. The Guide gives the choice to the Developers.
• Dropping the plan for the next day. A meeting that ends without one has done half its job.

How to practise it

Try a different format for one week and note how many blockers were noticed that day. In the simulator you take part in a Daily Scrum at step 3.2 and see how the choices you make in it change what the team does next.