Describe the change in state
Replace a list of activities with what is different now. “Read logs, tried a fix, attended a meeting” is a timeline. “The failure is isolated to retries after a connection timeout” is progress another engineer can use. A result can be a narrower question, a disproven hypothesis, or a clarified requirement; it does not have to be merged code.
Include only the context needed to connect that result to the team's work. If everyone knows the checkout migration, you may not need to reintroduce it. If dependencies span teams, name the affected capability instead of relying on an internal ticket number.
Make a blocker actionable
“Still blocked by the API team” does not tell anyone how to help. Explain what is missing, what it prevents, and the smallest action that would unblock you. For example: “I need the response shape for declined payments before I can finish the error path. Could someone confirm whether that field can be absent?”
Distinguish a blocker from an ordinary difficulty you are working through. If you have a reasonable next experiment, say that. If you need a decision or another person's access, make the request explicit and identify when the missing input affects delivery.
End with a next step
The next step should reduce uncertainty or move the deliverable forward. “Keep working on tests” is vague. “Reproduce the timeout with a fixed seed, then check whether retries are idempotent” tells the team what to expect.
Avoid turning the next step into an unsupported promise. If you do not yet know the cause, give a checkpoint: “I will post what I find after the reproduction test this afternoon.” That is different from guaranteeing the bug will be fixed today.
Move the deep dive out of the update
When someone needs implementation detail, offer a follow-up with the people involved. The standup can expose the dependency without becoming the place to solve it. A brief update followed by a focused discussion is often more useful than asking everyone to follow a debugging narrative.
Practice saying your update once and remove anything that does not change a teammate's next action. Keep important uncertainty and customer impact. The goal is coordination, not winning a contest for the shortest update.
Keep the decision in the explanation.
- Progress: what is different since the last update?
- Blocker: what prevents the next useful step?
- Next step: what will you do or who needs to help?
Same situation. Clearer explanation.
Yesterday I looked at the integration tests and then checked the logs. I tried changing the timeout, but that did not work. I also talked to Maya. Today I will keep looking.
I isolated the flaky checkout test to duplicate requests after a timeout. The first timeout change did not address it. Today I will reproduce the retry path and check its idempotency. I need someone familiar with the payment adapter to review that path with me after standup.
Illustrative examples. Adapt the facts and commitments to your situation.
Common mistakes to catch
- Narrating your calendar instead of the result.
- Using a ticket number as the entire explanation.
- Naming a blocker without a request.
- Hiding uncertainty behind “almost done.”
Now try saying it out loud.
Use the framework for one attempt. Listen back, choose one improvement, and try again.
Practice this conversationA couple of useful questions
What if I made no visible progress?
Explain what you learned, what you ruled out, or why the current approach is not working. Then state whether you have another experiment or need help choosing one.
Must every update include a blocker?
No. If you are not blocked, say that briefly or move directly to the next step. The framework is a coordination aid, not a script that requires invented problems.