Guide

How to write a daily standup update

Three questions, thirty seconds, and no performance. Here is the format, what a good answer sounds like, and what to do on the mornings you draw a blank.

Free plan forever. Pro trial included. No credit card required.

The three questions

Almost every standup, whatever the team calls it, is asking the same three things: what did you finish, what are you on now, and is anything in your way.

The first question is about yesterday, and it is the one people answer worst. It wants outcomes, not hours. What is different about the codebase now that was not different this time yesterday?

The second is about today, and it is a commitment, not a wish list. Name the one thing you expect to have finished by tomorrow morning.

The third is the only one that changes anyone else's day. If nothing is blocking you, say so in two words and give the time back.

What the difference sounds like

Weak

No information

Yesterday I worked on the API. Today I'll keep going on that. No blockers.

Three sentences, nothing in them. Nobody knows what shipped, what is left, or whether to worry. It is the update you give when you cannot remember the day.

Strong

Same length

Yesterday I finished the user creation endpoint and it returns the created record. Today I'm adding validation and tests. I'm blocked on staging database credentials.

Specific, states where each piece stands, and ends on the thing someone else can unblock. No longer than the weak one.

Five rules that make it better

  • Name the thing

    “The API” is not a thing. “The user creation endpoint” is. If a teammate cannot picture what you touched, the sentence has not landed.

  • Say what state it is in

    Started, finished, in review, blocked. Your team is listening for status, not activity. “I worked on it” tells them nothing they can act on.

  • Lead with the blocker

    If you are stuck, that is the only part of your update the room needs. Say it first, before anyone has stopped listening.

  • Keep it under thirty seconds

    Standup is a queue. Everything you say costs everyone else their turn. Detail belongs in the thread afterwards, not in the meeting.

  • Do not perform

    Nobody is scoring you on volume. A quiet day described accurately is worth more to your team than a busy day described vaguely.

The format is not the hard part

Nobody freezes in standup because they do not know the three questions. They freeze because yesterday has genuinely gone.

This has got worse, not better. When a model writes half your code, you reviewed and accepted the work rather than typing it, and accepted work does not stick in memory the way typed work does.

So people reconstruct. They scroll their commit history while the call waits, and read out messages written for a code reviewer, which is why so many updates sound like a changelog nobody asked for.

The fix is not a better format. It is having the answer already written down before anyone asks.

Questions

What if I did not finish anything yesterday?
Say what moved and what you learned. “I spent yesterday tracing why the webhook retries, found it is the timeout, fixing it today” is a complete and useful update.
How long should a daily standup update be?
About thirty seconds. Three sentences is usually enough: what you finished, what you are on now, and anything blocking you.
Should I mention a blocker I already solved?
Only if it cost real time or is likely to hit someone else. Otherwise it is history, and history belongs in the log rather than the meeting.
What if I genuinely cannot remember what I did?
Do not reconstruct it from commit messages while everyone waits. Keep a running log instead, so the answer already exists by the time you are asked.

Have the answer before they ask.

WriteLogs watches what you change and writes your day up for you, so standup is reading rather than remembering.

Free plan forever. Pro trial included. No credit card required.