Daily Standup: What to Say, and When to Skip It

A standup in agile is a short meeting, held every working day at the same time, where the people doing the work look at progress towards their goal, agree the plan for the next day and surface anything blocking them. In Scrum it is called the Daily Scrum and is timeboxed to 15 minutes. It is not a status report to a manager, and since 2020 the Scrum Guide no longer prescribes the three questions most people associate with it. Hold it when coordination is needed; skip it on the days a well-kept board already answers everything it would.

What the Scrum Guide says

The 2020 Scrum Guide↗ (opens in a new tab) gives the Daily Scrum one purpose: to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The rest of the section is short:

• It is a 15-minute event for the Developers, held at the same time and place every working day of the Sprint to reduce complexity.
• The Product Owner and Scrum Master take part as Developers only if they are actively working on items in the Sprint Backlog.
• The Developers can choose any structure and techniques, as long as the meeting focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.
• It is not the only time Developers may adjust their plan.

The guide also says Daily Scrums improve communication, identify impediments and promote quick decision-making, and so eliminate the need for other meetings. That is the test to hold a standup to: does it make other meetings unnecessary, or is it one more?

The three questions were dropped

The 2017 guide offered three questions as an example: what did I do yesterday that helped meet the Sprint Goal, what will I do today, and do I see any impediment. They became so familiar that many teams think they are the meeting. The Scrum Guide’s revision history↗ (opens in a new tab) lists removing the Daily Scrum questions among the changes that made the 2020 version less prescriptive.

The questions are not wrong; the trouble is what they do to the room. Each person faces the facilitator and reports their own day, the meeting becomes a round of individual status updates, and nobody talks about the goal. The Agile Alliance glossary↗ (opens in a new tab) names this as the first common pitfall: turning the meeting into status reports directed at management rather than an exchange between peers. Its other pitfalls are familiar too: running over time, people quietly “forgetting” to attend, and the “no problem” meeting where nobody raises an obstacle even though the team is plainly stuck.

What to say

Talk about the work, not about yourself. Useful contributions sound like this:

• “The payment change is waiting on a review. Can someone take it this morning?”
• “I finished the export. It is ready to test.”
• “The address lookup is harder than we thought. It might not fit, which puts the Sprint Goal at risk. Let us talk after.”
• “I am blocked on access to the staging database.”

What not to say: a list of meetings you attended, a narrative of yesterday, or anything that needs more than two people to resolve. Park those and pick them up straight afterwards with only the people involved. The Agile Alliance calls this a parking lot.

Three formats that work

Walk the board, right to left

Instead of going round the people, go round the work. Start at the column nearest done and move left: what is nearly finished and what does it need, then what is in progress, then what should start next. Finishing gets attention before starting, and items that have not moved for days stand out without anyone having to confess. This is a common practice rather than a rule from any guide, but it is the simplest fix for a standup that has become a status round. It needs a board everybody trusts; the GOV.UK Service Manual’s page on agile tools and techniques↗ (opens in a new tab) describes a team wall, physical or digital, as a shared visual record of the team’s work, and suggests keeping the standup to 15 minutes or less at the same time every day, in a format the whole team can join, including people working remotely.

Async written updates

For a team spread across time zones, a short written update can replace the meeting on most days. Keep the format tight, and write it against the work, not the person:

Finished: BUG-041 export totals (ready to test)
Moving: FET-018 card payments - review needed today
Blocked: ENH-022 - no staging database access, asked ops
Goal risk: address lookup may not fit this week

Written updates lose the moment when two people realise they are working on the same thing. Keep one live standup a week, or meet whenever an update says “blocked” or “goal risk”.

Standups with AI assistants in the loop

When coding assistants do part of the work, they will not be at the meeting, but their work should be. The practical change is to make the board the source, so the assistants’ progress shows up there before the standup starts. Ask each assistant to end its session by commenting on the task it worked on: what changed, what is left, and anything it could not do. Then walk the board as usual, and treat an assistant’s task like anyone else’s: if it has been in progress for three days, somebody asks why. A person still answers for every item an assistant touched, because an assistant cannot unblock itself by asking a colleague.

When to skip it

A standup exists for coordination. When there is nothing to coordinate, skip it. Good reasons:

• One person, or two who sit together all day. The coordination happens anyway.
• The board answers every question the meeting would: nothing blocked, nothing ageing, nothing waiting on someone else.
• Everyone is heads-down on work that was agreed yesterday and nothing has changed.
• The team has just held Sprint Planning or a review that covered the same ground.

Bad reasons: “we are too busy”, “nothing ever comes up”, or “the manager is away”. The first usually means the standup is needed most; the second is the no-problem meeting; the third suggests it was a status report all along. If you run Scrum, the Daily Scrum is one of the events, and the fix for a poor one is to change its format, not to cancel it for good.

What a board replaces

Most of what people say at a status-round standup is already on a well-kept board: what is in progress, what finished and who moved it. A board cannot replace the conversation about the goal, the moment someone asks for help, or the decision to drop an item that will not fit. Let the board carry the facts so the 15 minutes can go on those.

A standup on a fenbs board

fenbs has no sprints and no standup screen. It has four fixed lanes, To Do, Next Up, In Progress and Completed, which is exactly what walking the board needs: start at Completed, then In Progress, then Next Up.

• History records every change with who made it and when, including changes an AI assistant made on someone’s behalf, and can be narrowed by who made the change. Read it before the standup instead of asking everyone what they did.
• An assistant connected over MCP can post its end-of-session note with fenbs_comment, and list what is in progress with fenbs_list_items filtered to that lane.
• Flag a task for everyone on a team board when it needs the team’s attention; flag it for yourself when only you need the reminder. The note and comments still say why.
• The “Completed, not tested” filter shows what finished but has not been checked, which is often the most useful line of a standup.
• Copy as Markdown, below the board, gives you the lanes as text to paste into a chat channel for an async update.