Scrum Framework

Daily Standup

A 15-minute daily event for Developers to synchronise activities, inspect progress toward the Sprint Goal, and identify impediments needing removal.

Grad Junior Senior Test Lead

What it is

The Daily Standup is a short, focused inspection event held at the same time every day. It is strictly for the Developers. Many teams use the “three questions” format: What did I do yesterday? What will I do today? Any impediments? The purpose is for the team to plan the next 24 hours collaboratively. When someone mentions an impediment, it should be noted for resolution after the standup.

Not a status meeting. The Daily Standup is for the Developers, not a report to management or stakeholders. Its purpose is coordination and planning, not evaluation.

When to use it

Every working day during a sprint. Standups are most effective when held at the same time and in the same place (physical or virtual) to build habit and minimise friction.

Key benefits: rapid blocker identification, improved coordination, reduced ad-hoc meetings, shared accountability, and a daily reset of team focus on the Sprint Goal.

Key concepts

The Three Questions

The classic format asks each participant:

  1. What did I do yesterday that helped the team meet the Sprint Goal?
  2. What will I do today to help the team meet the Sprint Goal?
  3. Do I see any impediments that prevent me or the team from meeting the Sprint Goal?

Answers should be brief and focused on progress toward the Sprint Goal, not a laundry list of every email sent.

Walking the Board

Kanban-influenced teams often prefer “walking the board”: the team reviews work items on the board from right to left (closest to done first) and discusses what is needed to move each item forward. This keeps the conversation centred on flow rather than individuals.

Impediments and Blockers

An impediment is anything that slows the team down; a blocker stops work entirely. When someone raises an impediment, note it and move on. Deeper problem-solving happens in a “parking lot” or follow-up conversation immediately after the standup with only the people needed.

Time-boxing

The event is time-boxed to 15 minutes, regardless of team size. If the team cannot finish in 15 minutes, that is itself an impediment to inspect in the next Retrospective.

Common pitfalls

  • Status report to management. If managers attend, they should observe quietly. The Developers own the event.
  • Running over 15 minutes. Long standups lose energy and become meetings. Use a timer or token to enforce brevity.
  • Problem-solving during the event. Park deep dives for after the standup.
  • Skipping it. Missing standups quietly erodes coordination and delays blocker discovery.
  • Excluding remote members. Hybrid teams must design the standup so remote participants are first-class citizens—good audio, visible board, and equitable speaking time.

Red flag: If people start sitting down and bringing coffee, the standup has become a meeting. Reset the format in the next Retrospective.

NZ context

Distributed NZ teams (Wellington–Auckland–Christchurch) often run standups via video call. Effective teams keep them disciplined and short. Some New Zealand teams use async standups in Slack or Teams when time-zone or schedule gaps make synchronisation difficult, but nothing fully replaces the rapid back-and-forth of a live 15-minute sync when blockers are in play.

Career level guidance

Level Role in Daily Standup
Grad Attend daily, listen actively, learn the format, and answer the three questions concisely. Raise questions about unclear blockers after the standup.
Junior Participate actively, raise impediments early, and take notes on actions that affect your work. Offer to pair on blockers you can help with.
Senior Help unblock others, keep the team focused on the Sprint Goal, and facilitate the standup when the Scrum Master is unavailable. Model brevity and candour.
Test Lead Ensure quality and environment blockers are raised, coach the team on effective standup habits, and use the event to surface cross-team dependencies.
← Back to Agile Techniques Next: Sprint Retrospective →