English for Daily Standups: How to Explain Yesterday, Today, and Blockers Without Rambling

A standup is signal, not diary

The common “What did you do yesterday? What will you do today? Any blockers?” format is useful, but it is not a commandment from the Scrum mountain.

The current Scrum Guide says the Daily Scrum is a 15-minute event for Developers, focused on inspecting progress toward the Sprint Goal and adapting the plan. It also explicitly allows Developers to choose whatever structure and techniques work for that purpose. Atlassian describes Yesterday / Today / Blockers as a common standup pattern.

So if your team uses those three questions, great. Your language job is not to answer them like an autobiography. Give the information that helps the team move.

Yesterday: report the result, not the activity log

Compare these:

Grammatically valid but vague: Yesterday I worked on the payment API.

More useful for a standup: Yesterday I finished the timeout handling in the payment API and opened the PR.

The first sentence is not wrong. A listener understands that you spent time on the API. The likely standup intent, however, is to show what changed. The second version gives an outcome.

Useful patterns:

• I finished ___.
• I fixed ___.
• I got ___ working.
• I opened/submitted the PR for ___.
• I narrowed the issue down to ___.
• I tested ___ and found ___.

If the work is unfinished, do not invent a victory:

I made progress on the caching issue, but I haven’t confirmed the root cause yet.

Today: name the next concrete move

“I’ll continue working on it” is understandable, but it makes your coworkers perform psychic debugging.

Try:

• Today I’m adding the integration tests.
• Next I’ll reproduce the bug in staging.
• I’m going to update the migration and ask for a review.
• My next step is to compare the two logs and isolate where the requests diverge.

The goal is not fancy English. The goal is a next step someone could actually picture.

Blocker: say what is stuck—and what would unblock it

A blocker update becomes much more useful when it contains an ask.

Weak: I have a blocker with permissions.

Stronger: I can’t test the deployment because my staging account still lacks write access. Could someone from DevOps update the role today?

The first version is grammatically valid but underspecified. The listener knows a problem exists; they do not yet know the impact or the next useful action.

If you are waiting on someone

• I’m waiting on the schema change before I can finish the endpoint.
• The PR is ready, but I need one review before I can merge it.
• I’m blocked until we get the vendor credentials.

If it is a risk, not a full blocker

• This isn’t blocking me yet, but it could push the release if we don’t get an answer today.
• I can keep working on the UI, but the API uncertainty is a risk for tomorrow.

If you have no blocker

“No blockers” is perfectly natural. You do not need to discover a dramatic obstacle so your update has a satisfying third act.

Ramble Trimmer: can you compress these updates?

Say your shorter version aloud before opening each reveal. Aim for Result → Next → Blocker/Ask.

1. The Jira archaeology update

So yesterday first I checked the ticket and then I talked to Anna and after that I looked through some logs, and there were quite a lot of logs, and eventually I found that the retry job was creating duplicate requests, so I changed that part, but I still need tests.

2. The polite-but-hidden blocker

I’m working on the staging deployment. I tried a few things yesterday and maybe I’m missing something, I’m not sure, but basically I don’t seem to have the right access, so I’ll keep checking.

3. The honest investigation

I spent yesterday on the login bug. I think maybe it’s related to token refresh, but I’m not 100% sure yet and there are a few different possibilities.

4. The review request

I finished most of the changes and I think everything should be okay, and I put the PR up yesterday evening, so whenever someone gets a chance maybe they can look.

Useful English when you are not sure yet

Standups are full of unfinished facts. You need language between “I know exactly” and “uhhh… maybe?”

• I’m still investigating, but the strongest lead is ___.
• I haven’t confirmed the cause yet.
• So far, it looks like ___.
• I can keep moving on ___ while I wait for ___.
• If ___ doesn’t arrive today, it may affect ___.

These phrases do not magically make uncertainty disappear. They make its status clear.

The three-noun rehearsal

Before your next standup, do not write a paragraph. Write three nouns:

retry logic → tests → credentials

Then speak:

Yesterday I finished the retry logic. Today I’m adding tests. I’m blocked on credentials and need DevOps to update my staging role.

If your team prefers a different standup structure, adapt the exercise. The useful principle is the same: prepare signals, not a script.

Practice the update out loud

Once you can compress the content, you need to make the English easy to retrieve under meeting pressure. You can choose a speaking-practice path in FunFluen for more general output practice. This exact standup role-play is not preloaded there.

For more real-context learning workflows, browse the media-based language-learning guides.

Quick standup questions

Give the signal. Skip the documentary.

A useful daily standup update is not proof that you were busy.

What changed? What happens next? What could stop it—and who can help?

That is enough English to move the work forward. Your deleted Slack chronology will survive without a memorial service.

Sources

• The Scrum Guide: Daily Scrum
• Atlassian: Standups for agile teams