Running the Scrum Daily Standup (Daily Scrum)

Run the scrum daily standup as the Scrum Guide's Daily Scrum: a short daily event where Developers check progress against the Sprint Goal and replan.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

The scrum daily standup is the everyday name for the Daily Scrum, one of Scrum's five events. The Scrum Guide defines its purpose as "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 of the Scrum Team," held every working day of the Sprint at a fixed time and place. A Product Owner or Scrum Master who is working on Sprint Backlog items joins in as a Developer.

The guide leaves the format to the team. The Developers "can select whatever structure and techniques they want," as long as the Daily Scrum stays on progress against the Sprint Goal and "produces an actionable plan for the next day of work." That freedom predates the current edition. The Scrum Guide revision history records that the 2017 guide already said the Development Team sets the structure and offered the three questions only as an example, and that the 2020 edition removed the Daily Scrum questions as part of a move to make the guide less prescriptive. The familiar three questions about yesterday, today and impediments are now one option among many.

The event is often misused as a status report to a manager or Scrum Master. The 2013 revision already noted of the Daily Scrum, "Too often it is seen as a status event," and reinforced it as a planning event. An effective daily standup is a short working conversation among the people doing the work, about whether they are on track for the goal and what they will do next.

The guide also says the Daily Scrum "is not the only time Developers are allowed to adjust their plan." Detailed discussions happen afterward, with only the people who need to be there. This skill covers how to run the event well. For the rest of Scrum, see the Scrum method page.

How It Works

The Daily Scrum has one input and one output. The input is the current state of the Sprint Backlog: what is done, in progress, blocked or not started, measured against the Sprint Goal. The output is a plan for the next day, which may mean reassigning work, swarming on a stuck item, or asking the Product Owner to renegotiate scope. The Scrum Guide says Daily Scrums "improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings."

The daily standup format is the team's choice. The traditional format goes round the circle with three questions: what I did yesterday, what I will do today, and what is in my way. Before 2020 the guide phrased these around the team, such as "What will I do today to help the Development Team meet the Sprint Goal?" (revision history). The questions are easy to learn, but they tend to produce individual status updates.

A common alternative is to walk the board. Jason Yip's patterns for daily standups, published on martinfowler.com, describe structuring the meeting "by walking through each work item" on the team's board, from the end of the process to the start and from highest to lowest priority. He cites Pawel Brodzinski's default order: blockers, expedite items, items that have not moved since the last standup, then everything else. This keeps attention on the work and on finishing it.

Yip's article also names the patterns that keep the meeting healthy. "Same Place, Same Time" means the team starts on time without waiting for stragglers. "Take It Offline" is a simple phrase that moves problem-solving to after the meeting. "Rotate the Facilitator" spreads ownership. He also describes the failure mode "Reporting to the Leader," where people address a manager instead of each other, and notes that walking the board is especially prone to it unless the team rotates the facilitator.

Remote and hybrid teams need extra care. Atlassian's heuristic for remote teams is: "If one team member is remote, treat every team member as remote." Its tip for distributed teams is to have every team member join the video standup on their own computer (Atlassian on standups). Sharing the board on screen keeps a walk-the-board format working online.

Step-by-Step Guide

Step 1: Fix the time, place and timebox

Agree a time that works for every Developer and hold it every working day at a fixed time and place, as the Scrum Guide asks. Start on time even if someone is late. Keep the event within the guide's "15-minute" limit; a small team often needs less. For distributed teams, choose a time that overlaps everyone's working hours and use the same video link every day.

Step 2: Open with the Sprint Goal

Start by reading the Sprint Goal aloud or pointing to it on the board. Ask the question the event exists to answer: are we on track to meet it? This frames everything that follows around the team's shared objective. If nobody can say what the goal is, fix that first, with the Product Owner if needed.

Step 3: Walk the board

Go through the Sprint Backlog item by item, starting from the column closest to Done and moving left, highest priority first, as in Yip's Walk the Board pattern. For each item, the people working on it say what changed and what is next. Spend the most time on blocked items and items that have not moved since yesterday. If the team prefers the three questions, keep each answer tied to the Sprint Goal.

Step 4: Surface impediments

Anything blocking progress gets named clearly: what is blocked, what is needed, and who can help. Record it on the board so it stays visible. The Developers decide who will act on it today. If the impediment is outside the team's control, the Scrum Master takes responsibility for causing its removal, which the guide lists among the Scrum Master's services to the team.

Step 5: Adapt the plan

Before closing, agree what changes for the next day. That may mean two people swarm on a stuck item, someone pauses a new item to finish an old one, or the team asks the Product Owner to renegotiate scope because the goal is at risk. The guide requires the event to produce "an actionable plan for the next day of work," so end with that plan stated out loud.

Step 6: Take detailed discussions offline

When a conversation turns into problem-solving, use an agreed phrase such as "take it offline" and note who needs to meet afterward. Yip describes this pattern: acknowledge that the issue needs discussion, then have the right people pick it up after the standup. Hold those follow-ups right after the Daily Scrum while everyone is still together, and let the others get back to work.

Step 7: Review the standup itself

Every few Sprints, ask in the retrospective whether the Daily Scrum is helping. Signs it is not: people report to the Scrum Master, it regularly runs over, or problems come as a surprise at the Sprint Review. Atlassian notes that some of its teams discuss standup effectiveness in retrospectives and adjust the format (Atlassian on standups). Try one change at a time, such as walking the board or rotating the facilitator.

Best Practices

• Keep it for the Developers. The Scrum Guide makes the Daily Scrum an event for the Developers; if others attend, keep it from becoming a status meeting.
• Talk to each other. Facing the board or the team, rather than a manager, avoids the "Reporting to the Leader" failure that Yip describes.
• Focus on the work. Walking the board keeps attention on finishing items and on the Sprint Goal.
• Start on time, every time. Waiting for latecomers teaches everyone that the start time is optional.
• Rotate the facilitator. Rotation spreads ownership and stops the meeting depending on one person.
• Raise blockers as soon as they appear. The Daily Scrum is a safety net, and Atlassian notes it is not the only time to ask for help.

Common Mistakes

• Turning it into a status report: When each person justifies their day to a manager, the team stops planning together. Keep attention on how the work is moving toward the Sprint Goal and on tomorrow's plan.
• Solving problems in the meeting: Long technical discussions make the event run over and lose everyone not involved. Take them offline with only the people who need to be there.
• Running over the timebox: A Daily Scrum that routinely runs long becomes something people dread. Enforce the timebox and move detail to follow-ups.
• Holding it without a Sprint Goal: Without a goal, the meeting becomes a list of unrelated updates. Make sure every Sprint has a clear goal.
• Skipping days when things seem fine: Problems grow fastest when nobody checks. Keep the rhythm, and keep it short on quiet days.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Scrum

Related Skills

• Scrum Sprint Planning: Planning and Executing Sprints
• Managing Scrum Boards in Jira: Setup, Sprints, Reports
• Facilitating Sprint Retrospectives for Scrum Teams
• Defining Scrum Roles and Accountabilities
• Conducting Sprint Reviews: Run the Sprint Review Meeting
• Backlog Grooming and Product Backlog Refinement
• Scrum Estimation with Story Points and Planning Poker

Sources

• The Scrum Guide
• Scrum Guide revision history
• Jason Yip: It's Not Just Standing Up, Patterns for Daily Standup Meetings
• Atlassian: Standups for agile teams

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.