A great standup update has three sentences: what you finished, what you're doing next, and what's blocking you. That takes 15 to 30 seconds. If your standups regularly run longer than that, you're including details that belong in a Slack message or a one-on-one, not in a meeting where eight people are waiting for their turn.
The standup exists for coordination, not status reporting. Your team needs to know three things: what moved, what's moving next, and where you need help. Everything else, the technical details, the context about why something took longer, the caveat about a dependency, belongs in a follow-up conversation with the one or two people who actually need that information.
Most people know this intellectually. They still ramble in standups because they haven't practiced the format enough for it to feel natural. This post covers the formula, common traps, and how to train the habit so concise updates become automatic.
Why Do People Ramble in Standups?
Three reasons: they haven't prepared, they're performing, or they don't trust brevity.
No preparation. When you show up without reviewing what you did yesterday, your standup becomes a live recall exercise. You're searching your memory while talking, which produces filler words, tangents, and unnecessary detail as your brain processes in real time. Two minutes of pre-standup review eliminates this entirely.
Performance pressure. Some people use standups to demonstrate how hard they're working. The impulse is understandable, but the effect is the opposite: long updates signal that you can't prioritize, not that you're busy. The engineer who says "Shipped the auth fix, starting the payments API today, no blockers" sounds more competent than the one who takes two minutes to describe every subtask.
Distrust of brevity. If you're used to proving your value through volume of explanation, a 20-second update feels insufficient. It feels like you're not showing enough work. In reality, conciseness signals clarity. It tells the room that you've processed your work well enough to summarize it in one sentence.
What's the Best Format for a Standup Update?
The Done-Doing-Blocked framework. Three slots, one sentence each.
Done: What you completed since the last standup. Use past tense. Be specific about the deliverable, not the process.
Doing: What you're working on today. Use present or future tense. Name the task, not the activity.
Blocked: Anything preventing progress. If nothing, say "No blockers." Don't manufacture a blocker to fill the slot.
Example:
"Yesterday I shipped the password reset flow to staging. Today I'm starting the email verification endpoint. No blockers."
That's 22 words. It took 8 seconds. Every person in the room now knows your status.
Counter-example of the same update, unstructured:
"So yesterday I was working on the password reset thing, and it took a bit longer than I expected because the email service had some weird behavior with the token expiration, but I figured it out and got it working, and then I pushed it to staging. I also looked at some of the email verification stuff because I wanted to understand the flow before starting on it today. So today I'll probably work on that, the email verification, and hopefully get the endpoint done. I don't think there are any blockers right now, but I might need to check with the infrastructure team about the email provider limits."
That's 110 words. Same information. Five times the length. Every extra word diluted the signal.
How Do I Prepare for a Standup in Two Minutes?
Before the standup starts, write three bullet points: one sentence each for Done, Doing, and Blocked. This takes 90 seconds and transforms your update from a live recall exercise into a prepared delivery.
The preparation habit:
- Open your task board or yesterday's commit history.
- Write one sentence summarizing what you completed. Use a deliverable, not a process. "Finished the API endpoint" beats "Worked on the API stuff."
- Write one sentence about today's plan. Name the specific task.
- Check if anything is genuinely blocking progress. If yes, name it. If no, write "No blockers."
Read the three sentences once. That's your update.
This preparation step is worth emphasizing because it addresses the root cause of rambling: real-time improvisation. When you haven't decided what to say before the meeting starts, your brain has to simultaneously recall, evaluate, organize, and speak. That cognitive overload is exactly what produces filler words, tangents, and the verbal wandering that turns a 15-second update into a 2-minute monologue.
What Mistakes Make Standup Updates Worse?
Five common traps that inflate standups without adding value.
1. Process narration. "I started by looking at the database schema, then I realized the migration needed updating, so I spent some time on that, and then I moved to the controller logic." Nobody needs the narrative. They need the outcome: "Finished the database migration."
2. Premature problem-solving. "The API is returning 403s, and I think it might be a CORS issue, or maybe the token isn't refreshing correctly, so I was thinking we could try..." Stop. Name the blocker ("Getting 403s from the API") and take the debugging discussion offline with the relevant person.
3. Over-explaining blockers. "I'm blocked because the design team hasn't finalized the mockups, which I think is because they're still waiting on the content from marketing, who are dealing with the brand refresh." The useful version: "Blocked on final mockups from design." The extra context belongs in a DM to the design lead.
4. Hedging commitment. "I'll probably try to maybe work on the notification system if I get time." Replace with: "Working on the notification system today." If you're genuinely uncertain about your plan, that's a prioritization conversation for after standup.
5. Adding context nobody asked for. "Before I give my update, some context: I was out sick Monday, so I'm a bit behind, and also there was that deployment issue on Tuesday..." Skip the preamble. Lead with your point.
How Long Should a Standup Update Be?
Fifteen to thirty seconds, or roughly 35 to 75 words. In a 10-person standup, if everyone takes 30 seconds, the meeting finishes in 5 minutes. If everyone takes 2 minutes, it's 20 minutes, and by minute 8, half the room has mentally checked out.
Research on listener attention in group settings shows steep drop-offs after 60 seconds of continuous speech from a single speaker. In a standup format where contributions are expected to be brief, the drop-off is even faster: listeners calibrate their attention to the expected length. When you exceed that expectation, you lose them.
The 30-Second Rule: If your update takes more than 30 seconds, you're including information that belongs in a different conversation. Finish with "I'll sync with [person] on the details" and move on.
A useful self-check: can you deliver your update in a single breath? If you need to inhale mid-update, it's too long. This is the One Breath Test applied to standups.
How Do I Practice Giving Better Standup Updates?
Record yourself delivering a standup update and count the words. If it's over 75 words, cut until it's under 50. The editing process reveals which parts are signal and which are noise.
The Standup Drill: Every evening, practice tomorrow's standup update using Done-Doing-Blocked. Record it. Time it. If it's over 30 seconds, identify which sentence has excess detail and trim it. Do this for one week and concise standups will become automatic.
You can use the Speed Breakdown exercise for standup-specific practice: explain your day's work in 60 seconds, then 30, then 15. The 15-second version is your standup update. Everything you cut to get there was unnecessary.
The Wellspoken Index tracks conciseness through total word count, average sentence length, and redundant phrase detection. Recording your standup practice in the app shows you exactly where the bloat is and tracks your progress toward tighter delivery.
Key Takeaway
A great standup update uses the Done-Doing-Blocked framework: one sentence each for what you completed, what you're working on, and what's blocking you. Prepare in 90 seconds before the meeting by writing three bullet points. Keep the whole update under 30 seconds. Everything beyond that belongs in a follow-up conversation, not a group meeting where everyone is waiting for their turn.
FAQs
What if I didn't finish anything yesterday?
Say what you made progress on and be specific: "Made progress on the auth endpoint, finishing the token refresh logic. Continuing today." Saying "I worked on the auth endpoint" with no specificity sounds vague. Saying "I didn't finish anything" is unnecessarily negative. Focus on the progress and the plan.
How do I mention a blocker without starting a discussion?
Name the blocker and the person you need to resolve it with: "Blocked on API credentials. I'll follow up with DevOps after standup." This signals the issue without inviting the room to debug it live. If someone wants to help, they'll approach you after the meeting.
Should I mention things I did that aren't on the sprint board?
Only if they affected your capacity for planned work. "Spent two hours on a production incident" is relevant because it explains why your planned task isn't done. "Reviewed a PR and helped a teammate" is generally not worth mentioning in standup unless it shifted your priorities.
Practice delivering concise, structured updates with real-time feedback. Download Wellspoken