The Daily Standup

For anyone on a delivery team. The standup is the daily beat that catches a blocker the weekly product call is too slow for. This page prescribes how we run it. It adapts the patterns in Martin Fowler’s It’s Not Just Standing Up, the reference for what a standup is for and the ways it goes wrong.

What changes, at a glance:

You write your update before the session, never during it.
The session is fifteen minutes: five reading, ten solving.
The three columns are the same every day; you copy your row forward.
Every obstacle leaves the session with a named owner, or it wasn’t a standup.

Why we run one#

We are distributed and async by default: different countries, different timezones, no single room. That is deliberate, and it means a blocker or a quiet piece of drift has nowhere to surface on its own. Left alone, it waits for the next weekly product call, and a problem raised on a Tuesday can sit until Friday: three days of one person waiting on a decision or building against the wrong assumption.

The daily standup is the beat that closes that gap. Its job is not to prove everyone was busy. It is to put the day’s obstacles in front of the people who can clear them, while clearing them still changes the week.

Done well, most days it takes fifteen minutes, someone leaves unblocked who would otherwise have lost a day, and two people about to build the same thing find out before either starts. Done badly, it becomes a spoken status report that tells everyone what they could have read, resolves nothing, and quietly trains people to stop raising the problems that matter.

Write it before, solve it live#

The standard: your update is written before the session starts, so the session is spent solving problems, not reading them aloud.

This is the one move the whole page rests on. Updates are cheap to write and cheap to read. The scarce, expensive thing is fifteen minutes of the team’s shared attention, and spending it on “what I did yesterday,” which everyone could have read in silence, is the most common way a standup wastes a team’s morning.

So we split it:

Before the session: everyone fills their row in the standup table (below). No exceptions, including whoever is running it.
First five minutes, together: everyone reads. Silence is fine. You are hunting for the obstacles and the collisions, not admiring the done column.
Next ten minutes, together: you strategize. Unblock, decide, reassign, escalate. The output is decisions and owners, not a lap of the room.

This rules out three things:

Reading your status aloud. It is written. If your update is only ever spoken, you skipped the cheap half of the work.
A session that runs long. Fifteen minutes is the ceiling, not the target. Past it, attention is gone and you are in a meeting, not a standup.
Skipping the write-up to freeload on the live time. An empty row means the reading minutes get spent on you, out loud, which is the exact thing the format exists to kill.

Test: if the whole session could have been an email, someone skipped the writing. If the writing could have replaced the session, no one had a real obstacle, and that is a fine day to cancel.

The written update: three questions, one table#

One table, one row per person, three columns. You keep your own row and copy it forward each day, so the table is always today’s picture.

Person	🚀 Done since yesterday	Doing today	Obstacles someone needs to remove
Maya	Supplier import: parsing done, 3 of 5 formats passing	Last 2 formats, then wire to the staging queue	Need prod read access to the supplier bucket to test format 4

The order is deliberate: done, then today, then obstacles. The obstacles column is the one the session is actually for; the first two exist to give it context.

Write headlines, not narratives. The examples below are invented, and everyone writes the long version at first.

Done since yesterday

Bad: “Worked on the supplier import. Spent most of the morning on it, then got pulled into the onboarding thing, came back after lunch, still going.”

Good: “Supplier import: parsing done, 3 of 5 formats passing.”

Doing today

Bad: “Continue the import.”

Good: “Import: the last 2 formats, then wire it to the staging queue.”

Obstacles someone needs to remove

Bad: blank, or “a few things are slow.”

Good: “Blocked: need prod read access to the supplier bucket to test format 4. Nobody on the team can grant it. Need it today or format 4 slips to next week.”

A good obstacle names what is blocked, what you need, from whom, and what it costs if it waits. That is what makes it solvable in ten minutes instead of becoming a conversation about scheduling a conversation.

Make every line actionable#

The three columns tell you what to write. This is the bar for how you write each line: someone who was in none of your conversations can act on it without coming back to ask what you meant. It is the four questions applied to one row, and it is where most updates quietly fail, because the line reads fine to the person who wrote it. All examples below are invented, and every one is a mistake all of us have sent.

Link the thing you are talking about. Every item about a request, a doc, or a feature carries its link. Link it in the board the same way you @-mention a person, so a reader clicks through to the work instead of hunting for it or asking you which one you mean. A line about a piece of work with no link to the work is a line only you can follow.

Bad: “Confirmed the refund auto-reply copy with support.”

Good: “Confirmed the refund auto-reply copy with support, SUP-214.” (with SUP-214 linked to the request)

Say the outcome, not the topic. “Thinking about X” and “discussed X with Y” name what you touched, not what came out of it, and a reader cannot act on a topic. Give the decision you reached, or the specific question still open and who owns closing it.

Bad: “Been thinking about the refund copy, discussed it with Dan.”

Good: “Refund copy SUP-214: Dan and I settled on one short paragraph; I draft it today. Still open: link the policy page or inline it, deciding that with Priya.”

Name the real state, not a soft verb. “Clarified”, “handled”, “followed up”, “looked into” all hide the one thing the reader needs: what actually happened. Did you ask and you are now waiting? Did you get an answer? Did you decide it yourself? Say which, and name who you are waiting on.

Bad: “Clarified the scroll animation with the client.”

Good: “Asked the client to confirm the scroll animation; waiting on their reply, chased again today, need it by Thu or the build slips.” Or, once it is settled: “Client confirmed the scroll animation, clear to build.”

Put a person and a date on every intention. “Planning to discuss with Priya” is not a plan until it has a when. An intention with no time attached is the line most likely to read the same tomorrow, which is its own smell.

Bad: “Planning to discuss the refund copy more with Priya.”

Good: “Refund copy SUP-214: 15 min booked with Priya at 2pm today to settle the policy-link question.” Not booked yet? Then that is the obstacle, so put it there: “need 15 min with Priya today to unblock the copy.”

Close the loop with whoever is waiting. When a line means someone outside the standup is waiting on you, a client on an answer, a teammate on your piece, telling them is part of the item, not a separate afterthought. Name who you will update and when, or the work is finished on your side and still stuck on theirs.

Solve, don’t circle#

The ten minutes belong to the obstacles column. Walk the obstacles, not the people. Round-robin by name spends time on everyone whether or not they are stuck; walking the raised obstacles spends it only where work is actually blocked.

For each obstacle:

Name an owner and a next step. Not “we’ll look into it.” A person and a thing they will do. Track it until it is cleared. An obstacle raised three days running that no one owns is worse than one never raised, because the person learns that raising it does nothing.
Timebox. If clearing it needs a real dig, do not dig in the standup. Name who is in the dig and move on. The rathole that eats a standup is one problem being solved live while eight people watch.

Rotate who runs it. A fixed facilitator, especially a manager, turns the room back into status-to-the-boss, and people start reporting up instead of solving across. Rotating the seat keeps it the team’s meeting. Ownership of a specific blocker still follows the work: the DRI for that initiative owns clearing it after the session.

Across timezones#

Not everyone can make the live slot, and we do not pretend otherwise. The written table carries them: it is complete on its own, so someone offline reads it when their day starts and picks up the thread. If you will miss the session, still write your row before it, and write your obstacles so they can be actioned without you in the room: named ask, named person, named cost. An obstacle raised by someone who is not there still gets an owner in the session.

The live fifteen minutes are for whoever overlaps. If your team’s spread means almost no one overlaps, run the whole thing async: same table, and the strategizing happens in a thread hanging off the obstacles column instead of on a call. The rule that survives either way is the split: written first, then attention on the obstacles.

When it goes wrong#

Every one of these is common, and naming them is how you catch your own team drifting into one. (Framing adapted from Fowler.)

It becomes a status report. People take turns saying what they did while a manager nods. Fix: the doing is written; the session opens on the obstacles column, not the top-left cell.
Storytelling. An update turns into a narrative and the room checks out by the third sentence. Fix: headlines in the table, digs offline.
Obstacles get logged but not removed. The column fills up and nothing clears. This is the surest way to kill the standup, because people stop bothering. Fix: an owner and a date on every obstacle, tracked until closed.
Obstacles only ever surface at standup. If people sit on a blocker all day to save it for the session, the session has become the only sanctioned time to ask for help. Fix: standup is the backstop, not the gate; raise it the moment you are stuck.
The same row two days running. Your update is word for word what it was yesterday. That is one of two things, and both are worth catching: either nothing moved and you are stuck, in which case it is an obstacle, not a copy-paste, or the row is stale and no one can trust the table. Fix: if nothing moved, that is the blocker, put it in the obstacles column; if something moved, say what.
The empty row. Someone never writes their update and the team reads it off them live every day. Fix: no row, no floor; write it or the session moves on without you.