Mastering the Engineering Standup: English Tips and Example Scripts

The daily standup is one of the most frequent — and most underestimated — English speaking situations in a developer’s working day. It happens every morning, it is short, and it feels low-stakes. But if you consistently struggle to express what you are working on, if you speak for too long, or if you do not flag blockers clearly, it affects how your team perceives your communication. Getting standup English right is worth the effort.

The Three-Part Structure

The classic standup format has three questions:

1. What did I work on yesterday?
2. What am I working on today?
3. Do I have any blockers?

These three parts should take you under two minutes. The standup is not a status report meeting — it is a brief synchronisation check. Think of it as broadcasting your current state to the team, not presenting a detailed update.

Part 1: Reporting What You Did Yesterday

Useful Phrases

• “Yesterday I worked on / finished / completed the login page redesign.”
• “I made progress on the database migration — I got the schema changes done, but the data migration script is still in progress.”
• “I reviewed two pull requests for the authentication module.”
• “I spent most of yesterday on debugging a timeout issue in the payment service — I’ll come back to that.”
• “I wrapped up the feature branch and raised a pull request.”

What to Avoid

Do not over-explain. “Yesterday I worked on the API endpoint. I spent some time reading the existing code first, then I wrote the logic, and then I had to refactor it because I realised the data model had changed…” This level of detail belongs in a Slack message or ticket comment, not a standup.

Keep it to one or two sentences.

Part 2: Reporting What You Are Doing Today

Useful Phrases

• “Today I’m picking up the frontend integration for the API we discussed.”
• “I’m continuing with the migration script from yesterday.”
• “Today I’m planning to review the open PRs and then start on the notifications feature.”
• “I’m focusing on the database query optimisation.”
• “This morning I’m pairing with [name] on the deployment configuration.”

Signalling Uncertainty

It is completely normal not to be certain about what you will finish today. Signal that clearly:

• “Today I’m hoping to complete the draft — it depends on how the testing goes.”
• “I’ll aim to get the first version of the endpoint ready, but it may spill into tomorrow.”
• “I’m planning to start the UI work, but it depends on whether the design finalises today.”

Part 3: Blockers

The blocker section is the most important part of the standup. It is where the team can actually help each other. Many developers either skip it (“No blockers”) reflexively, or wait too long before escalating. If something is slowing you down, say it here.

Phrases When You Are Blocked

• “I’m blocked on the API keys for the third-party service — I’m waiting on [name] to get me access.”
• “I’m waiting for the design spec to be finalised before I can continue.”
• “I have a blocker I could use some help with — I’m hitting an intermittent test failure I can’t reproduce locally.”
• “I’m stuck on [problem] — I’ve been on it for about half a day and I’m not making progress. Could someone help me look at it after standup?”

Phrases When You Were Blocked But Are Now Unblocked

• “I was blocked yesterday on the environment issue — that’s resolved now, so I’m back on track.”
• “The access issue got sorted out this morning, so I’m good to continue.”
• “The PR was approved, so I’m unblocked and moving forward with the deployment.”

Flagging a Risk That Is Not Yet a Full Blocker

• “I have a potential blocker coming up — I need the database schema approved before I can write the migration, and that review hasn’t happened yet.”
• “This isn’t blocking me yet, but I want to flag that the timeline is at risk if we don’t get sign-off by end of day.”

Example Standup Scripts

Script 1: Normal Day

“Yesterday I finished the draft implementation of the search API — it’s passing all unit tests. Today I’m writing the integration tests and then I’ll raise a PR. No blockers.”

Script 2: In Progress, Uncertain Timeline

“Yesterday I started on the payment webhook handler. I got the basic structure in place but I’m still working through the retry logic. Today I’ll continue on that — I’m hoping to have it ready for review by end of day, but it might be tomorrow. No blockers at the moment.”

Script 3: Actively Blocked

“Yesterday I worked on the deployment pipeline for the staging environment. Today I was planning to test the full deployment, but I’m blocked — the staging credentials haven’t been provisioned yet. I’ve messaged [name] but haven’t heard back. Could someone help me chase that? Otherwise I’ll switch to reviewing open PRs while I wait.”

Script 4: Multiple Tasks

“Yesterday I split my time between two things: finishing the export feature and reviewing the three open PRs from the team. The export is done and merged. Today I’m moving on to the notifications work from the backlog. No blockers.”

Tips for Staying Under Two Minutes

1. Prepare before the meeting. Spend 30 seconds before the standup thinking through your three points. Do not improvise your entire update.
2. Use task names from the board. “I worked on PROJ-482” is faster than describing the task from scratch.
3. Say “no blockers” confidently if you have none. There is no need to add “I don’t think… well, nothing major…”
4. Take discussions offline. If a blocker sparks a longer conversation, say: “Let’s take this offline after the standup.” This is standard English phrasing every team will understand.

Key Takeaways

• Structure your update as: yesterday / today / blockers — in that order, every time.
• Keep it to one or two sentences per section and under two minutes total.
• Use “I’m blocked on” or “I’m waiting for” to signal blockers clearly and specifically.
• Hedge your today plans with “planning to”, “hoping to”, or “aiming to” when uncertain.
• The phrase “let’s take this offline” is the standard way to move a long discussion out of the standup.