A good standup update has three parts: what you completed, what you’re working on next, and any blockers. Each part should be one sentence. That’s it.
A clear standup update usually takes 30-60 seconds and keeps your team aligned without slowing the meeting down.
If you’ve ever overthought what to say in a standup, this guide gives you a simple template and phrases you can use immediately. For a broader look at how engineers communicate at work, see this guide on English for tech professionals.
A simple standup meeting template you can use every day
A good standup update follows the same three-part structure every time:
- Yesterday: what you completed
- Today: what you’re working on next
- Blockers: anything slowing you down
Keep it to one sentence per part.
Example standup phrases
Here are phrases you can use for each part right now.
Yesterday (what you completed)
– “I finished the API integration for the payments module.”
– “I reviewed and approved the two PRs from the frontend team.”
– “I wrapped up the unit tests for the user registration flow.”
Today (what you’re working on next)
– “I’m picking up the auth bug from the backlog.”
– “I’ll start writing the migration script for the database update.”
– “I’m pairing with Sara on the search performance issue.”
Blockers (what’s in your way)
– “I’m waiting on access credentials for the staging environment.”
– “I need a decision on the error-handling approach before I can move forward.”
– “No blockers right now.”
Notice how short these are. Each phrase is one sentence. That’s the goal. When thinking about what to say in a standup meeting, aim for one sentence per part. You don’t need transitions, background context, or apologies for what you didn’t finish. The daily scrum phrases that land best are specific and brief.
This structure works whether your team calls it a standup, a daily scrum, or a daily sync. The naming varies across teams and frameworks, but the language pattern stays the same. Memorize the three parts, swap in your own task details, and you have a repeatable template you can rely on every morning.
Standup meeting script for reporting progress
Your three-part structure gives you the skeleton. Now you need enough phrase variety so you don’t sound like you’re reading the same sentence every morning. A good standup meeting script covers two modes: what you finished and what you’re working on next.
When you finished a task
For the “yesterday” portion, pick the phrase that matches how far you got. “I finished the code review for the payments module” works when the task is done. “I wrapped up the unit tests for the search feature” is equally clean. When work carried over, try “I made progress on the migration script, it’s about 80% done” or “I spent most of yesterday debugging the timeout issue and narrowed it down to the caching layer.” If you context-switched, name both tasks: “I split my time between the API refactor and reviewing pull requests from the team.”
- “I finished the code review for the payments module.”
- “I wrapped up the unit tests for the search feature.”
When work is still in progress
For today’s plan, match your phrasing to the situation. “I’m going to start writing integration tests for the new endpoint” signals a fresh task. “I’m continuing with the database optimization from yesterday” tells the team you’re mid-stream. When your plan depends on someone else, say so directly: “Once I get the design specs, I’ll start on the front-end layout.”
- “I’m going to start writing integration tests for the new endpoint.”
- “I’m continuing with the database optimization from yesterday.”
- “Once I get the design specs, I’ll start on the front-end layout.”
- “I made progress on the migration script. It’s about 80% done.”
- “I spent most of yesterday debugging the timeout issue and narrowed it down to the caching layer.”
One pattern worth dropping immediately is over-hedging. Phrases like “I think maybe I’ll try to look into…” sound uncertain and bury your actual plan. Replace them with “I’m going to…” or “My plan is to…” Direct statements signal confidence and help your team understand your priorities faster. If you notice yourself stacking hedges in other meetings too, that’s a broader habit worth addressing. Working on how to stop rambling can help across all your work conversations. Strong standup meeting examples for developers share one trait: they state the work clearly and move on.
How to communicate blockers clearly and professionally
Flagging a blocker early signals ownership and proactivity. In English-speaking work cultures, raising an obstacle before it derails your timeline shows you’re managing your work. If your instinct is to stay quiet and solve it alone first, resist that. Teams expect blockers to surface in standups so they can help remove them.
The strongest standup blocker examples follow a two-part pattern. State the blocker factually, then state what you need or what you’ll do next. No apology, no long backstory. Compare “I’m sorry, I’ve been trying to figure this out for a while and I’m not sure what’s going on with the API” to “I hit an unexpected issue with the API rate limits. I need to investigate before I can move forward.” The second version is shorter, clearer, and more professional.
Communicate blockers: State the issue → State what happens next
Here are phrases you can adapt for common blocker types:
- Waiting on someone: “I’m blocked on the deployment. I need access credentials from DevOps.”
- Technical issue: “I hit an unexpected issue with the API rate limits. I need to investigate before I can move forward.”
- Dependency: “I can’t start the integration until the design team finalizes the endpoint spec.”
- Unclear requirements: “I have a question about the acceptance criteria on this ticket. I’ll reach out to the PM after standup.”
If you don’t yet have a clear answer about what’s blocking you, that’s fine too. You can say “I’m still figuring out the root cause” and follow up later. Having phrases ready for those moments helps you avoid sounding evasive.
Sometimes the issue isn’t a hard blocker but a risk worth mentioning. You want your team to know without triggering alarm. Try “This is taking longer than expected. I may need to push the deadline by a day” or “I want to flag that the scope on this ticket is bigger than we estimated.” Both of these standup meeting English phrases communicate a risk while showing you’re on top of it. You’re giving your team a heads-up, not delivering bad news. State the fact, state the impact, and move on.
Why short standup updates signal competence in English-speaking teams
That instinct to keep your update short isn’t about saving time alone. In most global tech teams, a concise standup update (roughly 30 seconds, two to three sentences) signals that you’re organized and in control of your work. A longer update often sends the opposite message. When someone takes two minutes to explain what they did yesterday, listeners start wondering whether that person is uncertain about their own progress or struggling to prioritize. Keeping it tight shows you’ve already done the thinking before you started talking. This kind of clarity is one of the fastest ways to stand out in tech, especially on global teams.
Directness matters as much as brevity. Saying “I’m blocked on the API credentials” lands better than “I’m not sure if maybe there could be a small issue with access.” Non-native speakers often soften statements out of politeness norms from their first language, and that instinct makes sense in many cultures. But in standups, hedging creates ambiguity. Your team can’t help you if they aren’t sure whether you actually have a problem. Stating blockers clearly is respected, not rude. If you want to work on this skill beyond standups, expressing yourself confidently in all meeting types follows the same principle.
A good rule of thumb for any standup update is two to three sentences total. If the topic needs more detail, say “I’ll follow up on Slack with the specifics.” This is a respected move on agile teams, not a cop-out. It shows you respect everyone’s time while still making sure nothing falls through the cracks.
Standup meeting template for async updates in Slack or Teams
Written standups on distributed teams follow the same three-part structure, but the format rewards even sharper brevity. Strip every filler word. Drop “I worked on” and “I was doing.” Go straight to the action and the ticket. Here’s a standup meeting template you can paste into Slack or Teams and fill in each morning:
✅ Yesterday: Completed PR for #342.
🔜 Today: Starting caching layer for search.
🚧 Blocker: Waiting on staging access from @ops.
Notice how each line is a fragment, not a full sentence. “Completed PR for #342” beats “Yesterday I worked on completing the pull request for ticket number 342.” In written standups, nobody misses the extra words. They actually slow readers down. Your teammates are scanning a channel full of updates, so density is a courtesy.
If speaking in standups still feels stressful, async updates are a low-pressure way to practice your phrasing. Write your update first, then read it aloud before your next live standup. Over a few weeks, the patterns stick, and the phrases start coming without the freeze.
Your standup meeting template cheat sheet
Bookmark this table and pull it up before your next standup. Every phrase below works in both spoken and written updates.
| Situation | Example phrase |
|---|---|
| Completed work | “Yesterday I finished the API integration for the payments module.” |
| Today’s plan | “Today I’m picking up the search filter ticket.” |
| Blocker (waiting on someone) | “I’m blocked on the deployment config. I’m waiting on DevOps to grant access.” |
| Blocker (technical issue) | “I hit a failing test in the auth service that I can’t resolve yet.” |
| Flagging a risk | “The timeline on the migration feels tight. I want to flag that early.” |
| Handling ambiguity | “I’m still investigating the memory spike. I’ll have more clarity by end of day.” |
| Async written update | “✅ Merged the cart fix. 🔜 Starting the checkout flow. 🚧 Waiting on design specs from Anna.” |
These standup meeting English phrases cover roughly 90% of what you’ll need to say. For anything outside these situations, follow the same pattern: state the fact, then state what happens next. That two-part structure keeps any update clear and short, no matter how complicated the underlying work feels.
Speak more confidently in your next standup meeting
You already know your work better than anyone on your team. Standup anxiety doesn’t come from a gap in technical knowledge. It comes from not having rehearsed phrases ready when the spotlight hits. That’s a language problem with a language fix.
Pick 2-3 phrases from this guide and say them out loud before your next meeting. After a few days, they’ll start to feel natural.
If you want to go further, practicing real meeting scenarios with feedback can accelerate progress. Tools like Talaera’s coaching and AI practice (Talk to Tally), designed for English for tech professionals, help you build confidence in the exact situations you face at work.
Frequently asked questions
What should I say in a daily standup meeting as a developer?
A standup update includes three parts: what you completed, what you’re working on next, and any blockers. Keep each part to one sentence.
How do I report a blocker in a standup meeting?
State the blocker clearly, explain the impact, and say what you need next. For example: “I’m waiting on API access, so I can’t test the integration yet.”
How long should my standup update be?
A good standup update takes 30-60 seconds. If it’s longer, move the details to a follow-up conversation or Slack message.
Can I use a written standup instead of speaking?
Yes. Many teams use async standups in Slack or Teams. The same three-part structure applies, but written updates should be even shorter and more direct.
How can I get better at speaking in standups as a non-native English speaker?
Prepare your sentences before the meeting and practice saying them out loud. Repetition builds confidence quickly. Practicing real scenarios with feedback, such as through Talaera or similar tools, helps you improve faster.
How can I improve my business English as an engineer?
Focus on the situations where communication affects your work, such as meetings, design discussions, and written updates. Improving your business English as an engineer means learning how to explain technical ideas clearly, align with stakeholders, and make decisions easy to follow. Practicing these skills in real scenarios helps you improve faster. For example, resources like Talaera’s Business English for Engineers focus specifically on how engineers communicate at work, from meetings to documentation and cross-team collaboration, so your English improves where it actually matters.
