Daily Standup
A 15-minute daily event for Developers to synchronise activities, inspect progress toward the Sprint Goal, and identify impediments needing removal.
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:
- What did I do yesterday that helped the team meet the Sprint Goal?
- What will I do today to help the team meet the Sprint Goal?
- 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. |
Industry Reality
- Most teams do run daily standups but rarely stick to 15 minutes — 20–30 minute overruns are common, especially when developers start problem-solving mid-meeting rather than parking issues for after.
- The "three questions" format is increasingly replaced by walking the board, particularly in teams using Jira or Azure DevOps; senior practitioners focus the conversation on flow rather than individual updates.
- Managers and product owners routinely attend standups, and in many NZ workplaces the event quietly doubles as a status report upward — experienced testers learn to give the Scrum Master the right signals to protect the format.
- Async standups (Slack threads, Geekbot, or Teams bots) are widespread for distributed NZ teams spanning Wellington, Auckland, and Christchurch, but they frequently miss nuance: a blocker flagged in a thread at 8 am can sit unacknowledged until the afternoon.
- On under-staffed NZ squads, the standup is often the only structured ceremony left after retrospectives and sprint planning get dropped under delivery pressure — making it the single daily checkpoint for quality concerns and test environment issues.
Context guide
How the right level of Daily Standup effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Government services team (e.g. CoverNZ, Benefits NZ, HealthNZ) under delivery pressure with distributed Wellington–Auckland members | Essential | Blockers in public-sector delivery compound fast across agencies; a missed standup means a blocker can sit unresolved for 24 hours, affecting citizens waiting on claims or benefit payments. |
| Startup or small fintech team (e.g. a KiwiSaver provider) co-located in one office with fewer than six developers | Essential | Small teams move fast and dependencies shift daily; the standup is the cheapest coordination mechanism available and prevents the silent assumption that someone else is handling a shared dependency. |
| Mid-size NZ bank (Harbour Bank, Pacific Bank) with a hybrid squad: some in-office, some remote, working on regulated features with compliance sign-off requirements | High | Compliance gates and sign-off dependencies make blockers disproportionately costly; a synchronous standup surfaces these before they cascade into sprint failure, especially when remote participants would otherwise miss in-office hallway conversations. |
| Mature platform team (e.g. TeleNZ, Pacific Air) with stable tooling, long-running infrastructure work, and high team autonomy | Medium | Low coupling between team members' day-to-day work means there is less to synchronise; a shorter or async standup may suffice, but retain a synchronous format when crossing team boundaries or during incident response. |
| Solo contractor or two-person team with a single workstream and no external dependencies | Low | With no coordination overhead, a formal standup is ceremony without benefit; a brief daily task-list review or a shared Jira board provides the same visibility at lower cost. |
| NZ government programme spanning multiple agencies (e.g. TransitNZ, LandNZ, FamiliesNZ) coordinated via a programme-level Scrum of Scrums | Essential | Cross-agency dependencies are high-risk because each organisation has its own change-approval cycle; the team standup is the first line of defence for surfacing inter-agency blockers before they miss a programme milestone. |
Trade-offs
What you gain and what you give up when you adopt Daily Standup.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Blockers surface within 24 hours and reach everyone simultaneously, including the Scrum Master who can act on them immediately. | Requires every team member to be available at the same time every day — difficult for teams spanning NZ and Australian time zones, or where flex work arrangements are the norm. | The team is fully async across three or more time zones with no two-hour overlap; use a structured async standup tool (Geekbot, Slack workflow) with a same-day escalation path for impediments. |
| A daily shared ritual builds team cohesion and psychological safety, making it easier for junior team members to raise concerns in a predictable, low-stakes forum. | Without discipline, standups inflate to 30-minute status meetings that drain energy and create the opposite of psychological safety, particularly when managers ask pointed questions in front of the group. | The team consistently runs over and the format has calcified into reporting; run a one-off facilitated Retrospective to redesign the format before abandoning the ceremony entirely. |
| Walking the board right-to-left optimises for finishing work rather than starting new tasks, which directly reduces WIP and improves sprint completion rates. | The standup format can create a false sense of coordination — teams can answer the three questions perfectly and still miss a shared dependency if neither party recognises the overlap. | The team has very low coupling (each developer works on wholly independent features with no shared test data or environments); use a shared Jira board with clear ownership columns instead of a daily ceremony. |
| Forces the team to articulate progress in plain language daily, which catches misaligned assumptions between developers and testers before they harden into integration failures. | A poorly run standup can actually conceal problems: teams learn to say "no impediments" to avoid scrutiny, meaning the ceremony becomes a mechanism for hiding rather than surfacing friction. | Trust between team members has broken down to the point where people are openly withholding information; fix the team dynamic via a facilitated Retrospective or coaching before reimposing daily transparency rituals. |
Enterprise reality
How daily standups actually run across 200–300-developer programmes at NZ banks, government agencies, and telcos — and where the cracks appear.
- Standup updates are automatically generated from Jira activity logs and Azure DevOps pipeline events, so developers are no longer summarising from memory — but this means blockers that exist outside the ticketing system (e.g. waiting on a verbal sign-off from a risk officer) are invisible unless someone explicitly raises them in the live call.
- At Pacific Bank, squads working on Payment Services delivery operate within a Change Advisory Board (CAB) cycle governed by PCI DSS requirements: a blocker that prevents a test environment from being stood up must be escalated as a formal change request, not just noted in a standup parking lot — teams that don't understand this distinction lose entire sprint cycles waiting for approvals that nobody submitted.
- Coordinating across 10 or more squads means a single team's standup is just one node in a Scrum of Scrums hierarchy — impediments that cross squad boundaries must be tagged and escalated to the programme-level sync the same day, otherwise they sit unresolved for 48 hours while each squad assumes the other is handling it; tooling such as Confluence decision logs and Microsoft Teams escalation channels is used to track these cross-squad blockers between synchronisation points.
- Multi-timezone delivery (Wellington, Auckland, and an offshore partner in Hyderabad or Manila) means the 9 am NZ standup excludes the offshore team entirely — large NZ government programmes such as those run by Revenue NZ under its Business Transformation programme have dealt with this by splitting into a daily async update for offshore contributors and a live synchronisation call at a time that overlaps NZ afternoons with early-morning offshore windows; the consequence of not solving this is that cross-timezone blockers routinely surface a full working day late, which on a fixed-price government contract is a material cost event, not a process inconvenience.
◆ What I would do
Professional judgment — when to adopt Daily Standup, when to adapt it, and what to watch for.
The bottom line: The standup is only valuable if people tell the truth in it — everything else (format, timing, facilitation) is secondary to creating the conditions where a junior QA on an Benefits NZ benefits team feels as safe raising a blocker as a senior developer does.
Best Practices
- ✓ Keep your own update to under 60 seconds — focus on progress toward the Sprint Goal, not a task-by-task rundown.
- ✓ Name blockers explicitly and immediately; don't soften them as "a bit delayed" — early, honest escalation is what the standup is for.
- ✓ If you raise an impediment, also flag who you need to resolve it so the right person stays after the standup.
- ✓ Walk the board right-to-left (closest-to-done first) to prioritise finishing work over starting new items.
- ✓ Use a visual timer or a physical token (e.g., a ball) to enforce time-boxing without awkward interruptions.
- ✓ Park anything that needs more than two sentences in a "let's catch up after" — write it on a sticky or in the chat so it doesn't disappear.
- ✓ For hybrid/remote teams, ensure the board is screen-shared and audio quality is confirmed before the standup starts, not during it.
- ✓ As a tester, use the standup to surface environment instability, test data gaps, or cross-team dependencies before they become day-long blockers.
Common Misconceptions
❌ Myth: The Daily Standup is a status report to management.
Reality: The standup is owned by the Developers and exists for team coordination, not upward reporting. Managers who attend should observe silently. If your standup feels like a status meeting, that's a team dynamic problem to raise in the Retrospective.
❌ Myth: If everything is going fine, the standup adds no value and can be skipped.
Reality: The standup's value is highest when things are fine — it keeps the team aligned so small drift doesn't become a large problem. Skipping it when things are smooth is exactly how coordination quietly breaks down mid-sprint.
❌ Myth: The three questions are mandatory and must be answered by everyone in turn.
Reality: The Scrum Guide 2020 removed the three questions as a requirement. Teams can use any format that achieves the goal: inspect progress toward the Sprint Goal and adapt the day's plan. Walking the board, round-robins, or hybrid formats all work if the outcome is coordination and blocker identification.
Senior engineer insight
Teams that get real value from standups treat them as a brief planning session, not a reporting ritual — the difference shows immediately in how people phrase their updates: "I need X from you before noon or we lose the day" versus "I was working on Y." The single pattern that separates high-performing NZ scrum teams from the rest is that they surface impediments the moment they appear, not after half a day of politely struggling alone, which means blockers rarely survive past the next standup.
The most common mistake: treating "no impediments" as the desired answer — teams that never raise blockers aren't running smoothly, they're hiding problems.
From the field
A Wellington squad building a government benefits portal assumed their 9 am Slack thread standup was equivalent to a live sync — everyone posted their three lines each morning and nobody said anything was blocked. Three weeks into a six-week sprint the team discovered that the Auckland dev and the Wellington QA had each been waiting on the other to resolve a shared test-data dependency that neither had flagged explicitly in text, because both assumed the other person had it under control. When they switched to a 15-minute Teams call, the dependency surfaced in the first standup — spoken aloud with both people on the call, it resolved in four minutes. The lesson generalised beyond that team: async standups flatten the nuance out of impediments; anything that requires two people to coordinate needs a synchronous signal, not a thread.
Why teams fail here
- The standup becomes a status report upward — when a manager asks direct questions during the event, the team starts optimising for how they look rather than what the team needs to coordinate; this is the single fastest way to kill psychological safety around blockers.
- Problem-solving in the room — two developers diving into a technical solution mid-standup burns the attention of everyone else and routinely blows the 15-minute box; park anything requiring more than two sentences.
- Repeating blockers without escalating — NZ testers in particular often re-raise the same environment instability day after day without demanding a resolution owner; if a blocker appears on three consecutive standups it is a process failure, not just a technical one.
- Remote members treated as passive listeners — on hybrid NZ teams, if the in-office participants are huddled around one laptop with bad audio, remote attendees stop engaging and start missing impediments that directly affect their work; equitable setup is not optional.
Key takeaway
A great Daily Standup is 15 minutes of the team honestly asking "what is in the way of us finishing this sprint?" — everything else is ceremony.
Self-Check
Click each question to reveal the answer.
Q: Your Scrum team is halfway through a sprint building the CoverNZ online claims portal. The Scrum Master is on leave. Who should run the Daily Standup, and what should change about the format?
A: The Developers own the Daily Standup — no Scrum Master is needed to run it. Any team member can facilitate, or the team can self-organise without a named facilitator. Nothing about the format should fundamentally change: the event stays time-boxed at 15 minutes, focused on progress toward the Sprint Goal, and parked deep dives for after. The Scrum Master's absence is not an impediment to running the event.
Q: You are a junior QA on an Benefits NZ benefits platform team. The test environment has been unstable for two days but you are worried about raising it again because it was already mentioned yesterday. What should you do at the standup today, and why?
A: Raise it again — clearly and with specifics. If the environment is still blocking testing, it is an active impediment and the team needs to know it has not been resolved. Softening or omitting a blocker to avoid repetition is exactly how impediments linger unresolved. State the impact concisely ("environment is still down, I cannot progress story X"), name who you need, and flag it for resolution immediately after the standup. Persistent blockers are a signal the team's impediment-removal process needs attention — surface that in the Retrospective.
Q: What is the key difference between "walking the board" and the traditional three-questions format, and when would you choose one over the other?
A: The three-questions format is person-centred — each team member answers what they did, will do, and any blockers. Walking the board is item-centred — the team reviews work items on the Jira/Trello/Azure DevOps board from right to left (closest to done first), discussing what is needed to move each ticket forward. Walking the board is preferable when the team wants to optimise flow and finish existing work before starting new items; the three-questions format can work better for smaller teams or teams new to Scrum who need a simple habit. Either format is valid under the 2020 Scrum Guide — choose what best serves coordination and Sprint Goal focus.
Q: A developer on your Revenue NZ tax-filing sprint says: "The Daily Standup is just overhead — we all sit next to each other and chat all day anyway, so we don't need a formal event." What is wrong with this reasoning, and how would you respond?
A: Informal hallway chats are not a substitute for a structured daily sync because they are uneven, unrecorded, and exclude anyone not physically present — including remote team members and anyone who arrived late that morning. The standup provides a guaranteed daily checkpoint where the full team inspects progress toward the Sprint Goal together, blockers are named explicitly in front of everyone (including the Scrum Master who can act on them), and the day's work plan is adapted as a group. Ad-hoc chat tends to reach only the people physically nearby, meaning blockers can go unannounced to the whole team for hours or days. The formal event also creates accountability: if you said yesterday you would finish story X, the team knows today whether you did.
How this has changed
The field moved. Here is how Daily Standup evolved from its origins to current practice.
Scrum formalises the Daily Scrum — a timeboxed 15-minute synchronisation meeting: what did I do yesterday, what will I do today, what blocks me?
Agile Manifesto cements the daily standup as a universal agile practice across XP, Scrum, and other methods. The 15-minute meeting replaces status emails and check-in meetings.
Distributed teams push standups to video calls. Async standups via Slack/tools emerge as an alternative for geographically distributed teams.
COVID-19 makes remote standups universal. Teams discover async standup tools (Geekbot, Status Hero) reduce meeting fatigue while maintaining transparency.
AI standup summaries generated from ticket activity reduce the ceremony for individual contributors while keeping visibility for leads and stakeholders. The standup's value as a human synchronisation moment remains even as its format evolves.