A useful standup update answers three questions: What changed since the last update? What will you move forward next? What could slow the team down? Lead with outcomes rather than a diary of tasks, name blockers early, and make a specific request when you need something. Most updates need only 20–40 seconds. A strong template is: "Yesterday I completed X, which means Y. Today I'm doing Z. The only risk is A; I need B from C."
It's your turn in standup. You know exactly what you worked on, yet your update comes out as either "still working on the ticket" or a five-minute tour through every file you touched.
The problem is not that you have nothing useful to say. It is that a standup compresses a complicated day into a few sentences, and most teams never explain what information belongs in those sentences.
This guide gives you a simple structure and 25 examples for the situations software engineers actually face: ordinary progress, blockers, uncertain investigations, invisible work, changing priorities, and remote coordination. If speaking in the meeting itself is the hard part, pair it with our guide to speaking up at work without being awkward.
A Standup Is a Coordination Tool, Not a Performance
A useful update helps teammates answer: Has something changed? Does this affect me? Is there a risk we should handle now? It is not a test of how busy you were, and it is not a status recital for your manager.
That distinction changes what you include. "I attended two meetings, answered Slack, and worked on ENG-241" lists activity but gives the team nothing to act on. "The payment retry is working in staging; it needs review before tomorrow's release" describes an outcome and a dependency.
Mention details when they change a decision. A database migration strategy matters if another engineer is building against it. The name of every helper function you refactored probably does not.
Imagine handing the team three signals: progress, next move, and risk. If a detail does not improve one of those signals, it can usually stay in the ticket.
The Outcome–Next–Risk Formula
Use three short parts. Outcome: what is now true that was not true at the last update? Next: what meaningful step will you move forward? Risk or request: what might delay the work, and what do you need from the team?
A default script is: "The new search endpoint is working in staging and the pull request is up. Today I'm addressing review comments and adding load tests. No blocker; it should be ready for QA this afternoon."
You do not have to force all three parts into every update. If there is no blocker, say "no blockers" or simply stop. If your team runs async standups, the same structure works in writing—use three bullets and link the ticket or pull request instead of pasting its history.
Outcome: what changed. Next: what you will advance. Risk/request: what the team can anticipate or unblock. That is enough for most updates.
Examples 1–5: Normal Progress
These examples lead with the result rather than a list of motions. Replace the specifics, not the structure.
1. Feature in progress: "The account export now handles CSV generation; the remaining piece is emailing the download link. I'll finish that today, then open the pull request. No blockers."
2. Pull request ready: "The rate-limit change is ready for review in PR 418. Today I'll respond to feedback and start the metrics dashboard. I need one backend reviewer before 2 p.m. to keep the release on track."
3. Work moved to QA: "The password-reset fix passed local and integration tests and is now with QA. Today I'm picking up the session-timeout bug. Nothing is blocked on my side."
4. Multi-day task: "The migration is about halfway through: the schema and backfill script are done, and validation is next. I'm still on track for Thursday. No new risks."
5. Small maintenance work: "I merged the dependency updates and confirmed the build is clean. Today I'll remove the deprecated API calls. One library has a breaking change, but I have a migration path."
Examples 6–10: Blocked or Asking for Help
A blocker is not a confession. It is information the team can use before a problem becomes a missed deadline. State what you tried, what is stopping you, and the smallest useful request.
6. Need technical help: "The webhook works locally but fails signature validation in staging. I've compared the secrets and logged the raw headers. I'm blocked now; could someone familiar with the gateway pair with me for 20 minutes after standup?"
7. Waiting on a review: "The accessibility fixes are complete, but deployment is waiting on approval for PR 612. I can pick up the next task meanwhile. Could Priya or Mateo review it this morning?"
8. Product decision needed: "The empty-state UI is built. I need a decision on whether archived projects appear in search before I can finish the query. Sam, could we settle that after standup?"
9. External dependency: "Our side of the SSO integration is ready. The vendor has not provided the test credentials, so end-to-end testing is blocked. I've followed up and flagged Friday as at risk."
10. Environment problem: "I can't reproduce the crash because the shared test environment is down. The logs point to the image processor, so I'm adding diagnostics locally. I need the environment restored to verify the fix."
If you tend to struggle in silence, use the same context-first pattern recommended in our guide to declining unnecessary meetings: show the relevant context, then make a clear request.
Do not hide a blocker behind "still investigating." If another person, decision, permission, or system is required, name it while there is still time to help.
Examples 11–15: Uncertainty, Bugs, and Slipping Work
Investigation is real work, but "I looked into it" is hard to interpret. Say what you ruled out, what you are testing next, and when the team will get a better forecast.
11. Investigation without a fix yet: "I reproduced the memory spike and ruled out the cache. Today I'm profiling the import worker. I don't have a reliable fix estimate yet; I'll update the ticket by 3 p.m. with what the profile shows."
12. Estimate changed: "The API change is larger than expected because two mobile versions depend on the old response. The original Wednesday estimate is no longer realistic. I'm mapping the compatibility options this morning and will bring a revised estimate to planning."
13. Bug re-opened: "The timezone bug came back in QA for daylight-saving dates. I have a failing test now and will fix against that case today. This may move release verification from morning to afternoon."
14. Spike produced a decision: "The prototype showed that client-side filtering will not handle the expected dataset. I recommend server-side search. I'll document the trade-off and split the implementation into tickets today."
15. Scope is unclear: "I completed the known validation rules, but the ticket is ambiguous about imported records. I've listed the two interpretations. I need product to choose one before I can give a finish date."
Examples 16–20: Work That Is Hard to See
Reviews, incident response, support, mentoring, and discovery may not create a shiny new feature. Explain the effect of the work without inflating it.
16. Code reviews: "I finished the checkout and analytics reviews, which unblocked both releases. Today I'm returning to the notification settings feature. No blockers."
17. Production support: "I paused feature work to investigate the elevated error rate. The bad configuration is rolled back and the service is stable. I'll document the cause this morning, then resume the feature after lunch."
18. Pairing or mentoring: "I paired with Lee on the permissions issue and we found the missing policy check. Their fix is in review. Today I'll finish the admin audit endpoint."
19. Planning and discovery: "I mapped the upload flow and found that virus scanning is the main dependency. Today I'm meeting security to confirm the requirements, then I can split the work and estimate it."
20. Refactoring: "I separated the billing calculation from the controller and kept behavior covered by the existing tests. That clears the path for the discount feature; today I'll add its first rule."
Examples 21–25: Priority Changes and Team Coordination
When priorities or availability change, make the trade-off visible. The goal is not to apologize for reality; it is to keep everyone working from the same reality.
21. Priority changed: "I switched from reporting to the login incident at noon, so the export task did not move yesterday. The incident is resolved. I'll resume export today; its expected finish moves to Thursday."
22. Two competing requests: "I have the dashboard fix and the partner API request both marked urgent. I can finish one today, not both. Morgan, can you confirm which has priority after standup?"
23. Handoff: "The backend endpoint is deployed and documented. Frontend can now integrate against staging. I'll be available this morning for questions, then I'm moving to the audit-log task."
24. Returning after time off: "I'm catching up on the release changes this morning, then I'll continue the search ranking work. I don't see a blocker yet; I'll flag anything that changed the assumptions in my ticket."
25. No meaningful change: "No change on the payment task since yesterday because I spent the day on interviews. I'm back on it this morning and still expect the pull request tomorrow. No blocker."
How to Keep the Update Short Without Leaving Things Out
Give the headline in standup and move the investigation elsewhere. Try: "The mobile build is blocked by an iOS signing issue. Chen and I need ten minutes after standup; everyone else can find details in the ticket."
Avoid narrating your debugging path unless the team needs to choose the next branch. Avoid ticket numbers without meaning. And avoid saying "no blockers" when you are actually waiting for a decision—waiting is a dependency even if you have other work to do.
If you ramble when nervous, write three fragments before the meeting: changed / next / risk. Read them if needed. Clear communication matters more than sounding spontaneous, and rehearsal is a legitimate way to build the skill; our guide to practicing social skills alone explains how to make rehearsal useful.
Your Action Step
Before your next standup, write one sentence for each part of the Outcome–Next–Risk formula. Then remove any detail that belongs in the ticket and make every request name an owner or next step.
Do not aim to sound impressive. Aim to make the team's next few hours easier to coordinate. That is what a good standup update is for. Browse more work communication guides or use the Communication Trainer to rehearse a difficult update before you deliver it.
Frequently Asked Questions
What should a software engineer say in a daily standup?
Share the outcome of your recent work, your next useful step, and any blocker or risk the team should know about. For example: 'The checkout fix is in review. Today I'll add regression tests and prepare the release. I'm waiting on product to confirm the guest-user behavior.'
How long should a standup update be?
Aim for roughly 20–40 seconds when work is moving normally. Take longer only when the team needs context to coordinate. If a topic needs problem-solving, name it, identify who should stay, and continue after standup rather than turning everyone's update into a technical meeting.
What do I say when I have no progress to report?
Say what affected progress, what you learned, and what happens next. 'I didn't get to the API task because I handled the production alert. The alert is resolved; I'll start the API work this morning.' Honest context is more useful than making routine activity sound like progress.
Should I mention every task I worked on in standup?
No. Mention work that changes the team's understanding of delivery, dependencies, or risk. Small activities can be grouped under the outcome they support. Your ticket tracker can hold the full activity log; standup is for coordination.
Your next real-world rep
Ask a question in front of people
Ask one question in a public setting today — in a meeting, at a talk, in a class. Write it down first if you need to, then raise your hand before the doubt wins.
Try this challenge →Simon H.
Simon is the founder of Communication for Nerds. A lifelong nerd, he learned social skills the way he learns everything else: by breaking them into systems, practicing small reps, and keeping what works. Every guide here is what he wishes someone had told him earlier. Read his story →
