Module 5: Spoken Technical English
3. The Daily Standup
Description
If speaking English at work scares you, the standup is the best place to start, and it's no accident that we put it so early in the module. Of all the situations where you're going to open your mouth in English — pairing, the demo, the interview, the meeting with five different accents — the daily standup is the shortest, the most predictable, and the most repetitive. Short because your turn lasts under a minute. Predictable because it always answers the same three questions, in the same order, every day. And repetitive because it happens every morning, so you don't have to invent the practice — the calendar hands it to you. A thirty-second script you say once sounds like an exam; the same script said twenty mornings in a row turns into something that comes out on its own.
That's exactly what someone who freezes up on the call needs. Linguistic impostor syndrome — that voice telling you "I don't speak enough English for this" — feeds on the open-ended and the unpredictable: not knowing what you'll be asked. The standup removes almost all of that uncertainty. There are no open questions, no improvising on a topic you don't control, no ten-minute conversation to hold up. There are three sentences about your own work, which is the one topic in the world you know best. You're not going to learn "general fluent English" here — that's not what this guide promises, and it would be lying to you — you're going to learn to say three specific things well, and to say them with the confidence of someone who's rehearsed them.
Connection to the module: This is your first real speaking territory, and that's why it comes before open meetings, pairing, or the demo. Here you retrieve the active vocabulary you built in module 2 and the past- and future-tense structures you internalized in modules 3 and 4: the standup is literally "what I did (past), what I'll do (future), what's blocking me (present + request)." Once you no longer have to think about those structures, speaking stops being invention and becomes retrieval. We'll work in depth on the skill of asking for clarification when you don't understand someone, and on taking the floor in a meeting where several people are talking, in lessons 4 and 5; here we focus on your own report.
What a standup is, and why it lasts under a minute
The daily standup (also just called the daily, or daily scrum) is a short meeting the team holds every day, almost always at the same time and almost always in the morning. The name comes from a literal idea: it used to be held standing up, precisely so nobody would get comfortable and the meeting wouldn't drag on. The most useful analogy is a traffic light: you're not there to tell the story of your journey, you're there to give a quick signal of whether you're green, yellow, or red, and move on.
The golden rule is this: the standup isn't for solving problems, it's for making them visible. If something needs discussion, it gets set aside for later ("let's take it offline," you'll see that phrase in a moment). That's why your turn has to fit under a minute: if every person on an eight-person team talks for two minutes, the "fifteen-minute" meeting turns into sixteen, and everyone starts showing up late and hating it. A short turn doesn't mean you have little to say; it means respect for everyone else's clock.
What to expect the first time: you'll probably have to listen to three or four updates before yours, and that's already real listening practice (short updates, sometimes in accents that don't match a course recording). It's fine if you don't catch every word of what a teammate said: in the standup you only need to understand each person's headline — what they're working on and whether they're blocked — not the fine detail. Your own turn, though, you bring already prepared.
The three-point format
Almost every standup in the world, at any company, follows the same three-question template. Memorize it once and it serves you your whole career:
| # | Question (in English) | What you report | Verb tense |
|---|---|---|---|
| 1 | What did you do yesterday? | What you finished or made progress on yesterday | Past |
| 2 | What will you do today? | What you plan to do today | Future |
| 3 | Are you blocked by anything? | What's holding you back, if anything | Present + request |
That's the whole exam. And notice something that should take a weight off your shoulders: each point has a fixed verb tense. Point 1 is always past, point 2 is always future, point 3 is present with a request. You don't have to decide on the spot which structure to use; the question already picks it for you. That's why we said earlier that here you only retrieve what you built in modules 3 and 4 — you don't invent it.
A vocabulary detail: you'll see many teams say yesterday even when the last working day was Friday and today is Monday. If you want to be precise, you say since my last update, which covers any weekend gap or days off without you having to do the math.
Phrase bank: point 1, what I did (past)
Here are ready-made sentences for the first point. Don't mentally translate them word by word; learn them as blocks you say whole. The part in <...> is what you swap for your real work.
- Yesterday I finished
<the login endpoint>. (Ayer terminé el endpoint de login.)- I wrapped up
<the migration script>and it's ready for review. (Terminé el script de migración y está listo para revisión. Wrap up = "cerrar/dar por terminado", muy común.)- I made progress on
<the caching layer>, it's about<70>percent done. (Avancé en la capa de caché, va como al 70 por ciento.)- I picked up
<ticket 412>and started digging into it. (Tomé el ticket 412 y empecé a meterme en él. Dig into = "investigar a fondo".)- I paired with
<Ana>on<the auth bug>and we tracked it down. (Hice pairing con Ana en el bug de autenticación y lo localizamos.)- I opened a PR for
<the retry logic>, it's up for review. (Abrí un PR para la lógica de reintentos, está listo para que lo revisen.)
Two verbs worth their weight in gold for this point: finished (something completely closed) and made progress on (something still open). With those two you cover 80 percent of your mornings. If you want to sound a notch more natural, I wrapped up and I picked up are the versions people use day to day.
Phrase bank: point 2, what I'll do (future)
For the second point, standup technical English almost always uses one of two structures: I'm going to or simply I'll. Both are fine; pick whichever comes out more fluidly for you.
- Today I'm going to
<finish the tests for the endpoint>. (Hoy voy a terminar los tests del endpoint.)- I'll pick up
<the code review>I couldn't get to yesterday. (Voy a retomar la revisión de código que no alcancé ayer. Get to = "llegar a hacer algo".)- I'm planning to
<start the integration with the payments API>. (Tengo planeado empezar la integración con la API de pagos.)- My focus today is
<getting the deploy pipeline green>. (Mi foco de hoy es dejar el pipeline de deploy en verde. Green = "que pasa/está OK".)- I'll continue with
<the caching layer>and hope to have it ready for review by<end of day>. (Sigo con la capa de caché y espero tenerla lista para revisión al final del día.)
A trick to connect point 1 and point 2: if you made progress on something yesterday and you're finishing it today, link them with I'll continue with... or I'll wrap up.... That shows the team the continuity of your work without you having to explain anything more. It sounds like someone who knows where they're headed.
Giving enough context without narrating your whole day
This is where most people get tangled up, and not because of the English — because of the instinct to over-explain. When you're nervous, you tend to compensate by talking more, because an uncomfortable silence is scary. In the standup that works against you: the longer your turn, the more you expose yourself to getting stuck, and the more impatient the team gets.
The practical rule is one to two sentences per point, and that's it. Compare:
Too much (narrating the whole day): "So yesterday I started looking at the login thing, and first I read the old code, which was kind of confusing, and then I realized the token wasn't being refreshed, so I looked at how the other service does it, and I tried a couple of things, and eventually..."
Enough (one clear headline): "Yesterday I fixed the token refresh bug in login. Today I'll add tests for it. No blockers."
The second version says everything the team needs in three sentences and fifteen seconds. The detail of how you solved it — the confusing old code, the attempts, the other service — is exactly what you save for pairing or for the PR, not for the standup. If someone's interested in the detail, they'll ask you afterward.
A mental test that saves you: before speaking, ask yourself "what's the headline?" If you had to sum up your day in a news headline, what would it be? "Fixed the token bug" is a headline. "Read some confusing old code and tried a few things" is not. Say the headline, offer one sentence of context only if it's genuinely needed, and close.
Reporting a blocker in twenty seconds
The third point — the blocker — is the most important part of the whole standup, and the one most people report badly. A blocker is anything that stops you from moving forward and that you can't solve on your own: a permission you don't have, a decision that isn't yours to make, a response you're waiting on from someone else, an environment that's down. The standup exists largely for this: so blockers surface early and someone can unblock you.
A good blocker report has three parts and fits in twenty seconds: what's blocking you, who or what can resolve it, and exactly what you're asking for. The piece people forget most is the last one. A bare "I'm blocked" leaves the team guessing what you need; "I'm blocked and I need X from Y" turns your problem into a concrete action someone can take.
| Part of the blocker | In English | Example |
|---|---|---|
| What's holding you back | I'm blocked on / by... | I'm blocked on the staging deploy. |
| Who/what resolves it | I need <X> from <Y> | I need the API keys from the platform team. |
| What you're asking, concretely | Could someone...? / Can we...? | Could someone point me to who owns that? |
Full model sentences for point 3:
- I'm blocked on
<the staging environment>, it's been down since yesterday. Who can I talk to about that? (Estoy bloqueado por el ambiente de staging, lleva caído desde ayer. ¿Con quién puedo hablar de eso?)- I'm waiting on
<the API credentials>from<the platform team>. Could someone help me chase that? (Estoy esperando las credenciales de la API del equipo de plataforma. ¿Alguien me ayuda a darle seguimiento? Chase = "perseguir/dar seguimiento".)- I need a decision on
<whether we support the old format>before I can move forward. (Necesito una decisión sobre si soportamos el formato viejo antes de poder avanzar.)- I'm stuck on
<the failing test>, I've been at it for a while. Could I grab<15 minutes>with someone after this? (Estoy atorado con el test que falla, llevo rato. ¿Podría agarrar 15 minutos con alguien después de esto?)
Notice the pattern in that last one: you're not trying to solve the problem in the standup — that would break the golden rule — you're asking for time afterward to solve it. That's the most professional move that exists in a standup: you make the blocker visible, you ask for something concrete and bounded, and you free up the meeting. The phrase for that, which you'll hear a thousand times, is "let's take it offline": when a topic is dragging on, someone says it and everyone understands it gets picked back up outside the standup.
And when you're not blocked, which will be most days, you have three short ways to close, all perfectly natural:
- No blockers. (Sin bloqueos.)
- Nothing blocking me. (Nada me frena.)
- All good on my end. (Todo bien de mi lado.)
What to say when you didn't make progress
This is the moment that scares people most, and it's worth having a plan for it, because it happens to everyone, seniors included. Yesterday you didn't make progress: a meeting ate your day, you went down a rabbit hole that led nowhere, or the problem was simply harder than it looked. The temptation is to make something up, dress it up, or hide it. Don't: on a healthy team, calmly saying that a day didn't pay off is a sign of maturity, not weakness. What costs you credibility isn't failing to make progress — it's pretending you did.
The key is to be honest about the past and concrete about the plan. Don't over-apologize or give a speech; say what happened in one sentence and where you're headed in the next.
- Yesterday didn't go as planned,
<I got pulled into some production issues>. Today I'm back on<the caching work>. (Ayer no salió como estaba planeado, me jalaron a unos problemas de producción. Hoy retomo el trabajo de caché. Got pulled into = "me metieron a / me jalaron a".)- I didn't make as much progress as I wanted on
<the migration>— it was trickier than I expected. I'll keep at it today. (No avancé tanto como quería en la migración, resultó más engañosa de lo que esperaba. Hoy le sigo. Keep at it = "seguir dándole".)- Honestly,
<the bug>turned out to be deeper than I thought. Today I'll<pair with someone to get unstuck>. (La verdad, el bug resultó más profundo de lo que pensé. Hoy voy a hacer pairing con alguien para destrabarme.)
Notice how the last one turns a slow day into an action: if the problem was bigger than expected, the mature response is asking for help today, and you announce exactly that in the standup. An "I didn't make progress" that comes with a plan for how you will make progress today sounds like someone in control, not someone lost.
And there's an antipattern worth naming: avoid a bare "I'm still working on it," day after day, with nothing else. Repeated, it sounds like you're stuck and not saying so. If you genuinely are still on the same thing, ground it: "I'm still on the migration — the tricky part is the data validation, and I expect to finish that today." That's no longer an excuse — it's a report.
Putting it all together: a complete standup
This is what a complete, well-built turn sounds like from start to finish. Read it out loud once and time it: it should be between twenty and thirty seconds.
"Since my last update, I finished the token refresh fix and opened a PR — it's up for review. Today I'm going to add the integration tests for it and then pick up ticket 412. I'm blocked on one thing: I need the staging credentials from the platform team, so if someone can point me to the right person, that'd help. Otherwise, all good."
Broken down, so you can see the machinery: first sentence, past (what I did, headline first). Second sentence, future (what I'll do today, two concrete things). Third, the blocker with its concrete request ("I need X from Y, help me reach the right person"). Short close. Three points, thirty seconds, zero improvisation. None of that was invented on the spot: every piece came from a phrase bank you already had.
Timed practice: scripted and unscripted
This is where this lesson becomes yours, and where it connects with the practice cadence you built in module 1. Writing isn't enough for speaking: speaking is a different muscle that only trains by talking out loud, against a stopwatch, and listening to yourself. Here's the plan for the week between this lesson and the next.
Phase 1 — Scripted (days 1 to 3). Write your real standup for tomorrow using the phrase banks above. Three sentences, one per point. Then:
- Record yourself reading it out loud with the stopwatch running. Target: under forty seconds.
- Listen back. Don't judge your accent — you already worked on that in the previous lesson, and it's not the point here — just check two things: did the headline for each point come through? Did you ask for something concrete if you were blocked?
- Repeat until it comes out fluidly and under time. "Fluid" doesn't mean perfect; it means no long pauses where you're hunting for a word.
Phase 2 — Unscripted (days 4 to 7). Now put the paper away. Look at just three key words — one per point, for example token / tests / staging — and say the full standup from memory, recording yourself. It's going to feel worse than with the script, and that's fine: that's what the real muscle working feels like. The goal isn't repeating the script word for word; it's having the phrase-bank blocks come out on their own from the key word.
What to expect from this practice: the first recordings are going to make you uncomfortable — almost all of us hate hearing our own voice in another language — and you'll want to delete them. Don't delete them yet: keep them. At the end of the week, listen to day 1's and day 7's back to back. The difference you'll hear is the proof, in your own voice, that this is possible. That's the real antidote to impostor syndrome: it's not someone telling you "you can do it," it's hearing yourself actually do it.
A note on the module's gate: if while doing this practice you find that not even with the script can you hold thirty seconds without getting stuck on every word, it's not that this lesson is broken — it's a sign that your speaking floor still isn't solid, and it's worth reinforcing general spoken English before moving on to this module's more open lessons. The standup is the most protected speaking situation there is; if this one already flows, lessons 4 through 7 will be tough, but they're reachable. That's exactly the order we've been careful to protect.
Common mistakes and how to avoid them
| Mistake | How it sounds | Fix it like this |
|---|---|---|
| Narrating the whole day | "...and then I looked at, and then I tried..." | Say the headline: "I fixed the token bug." |
| Blocker with no request | "I'm blocked." (and silence) | "I'm blocked on X, I need Y from Z." |
| Repeated "Still working on it" | Sounds like you're stuck and not saying so | Ground it: "The tricky part is X, done by end of day." |
| Over-apologizing | "Sorry, I really didn't do much, sorry..." | Honest and short: "Yesterday didn't go as planned." |
| Solving the problem in the standup | Your turn stretches to three minutes | "Let's take it offline." |
| Translating word by word from Spanish | Long, odd sentences | Use the phrase-bank blocks as they are |
Exercises
These exercises work on what this lesson really teaches: compressing to a headline, structuring a blocker in three parts, spotting the most common antipatterns, and reporting a slow day without over-apologizing. Work through them out loud if you can — this is a speaking lesson, not just a reading one — and compare after you've tried.
Exercise 1 — Find the headline. This standup is told as if it were the full chronicle of the day, not a thirty-second report. Apply the headline test ("what's the headline for each point?") and compress it to the format's three points.
"So yesterday I spent basically the whole morning trying to figure out why the login endpoint was failing, and it turned out to be a token issue, so I fixed that, and then in the afternoon I also looked a little bit at the migration script but didn't really finish it, and today I guess I'll try to finish the migration and maybe also look at that code review that's been sitting there for a while, and I don't think I'm blocked on anything really, maybe just waiting a little on some feedback but it's not urgent or anything."
See solution
Something like this, one headline per point:
- Point 1 (past): "Yesterday I fixed a token issue in the login endpoint and made progress on the migration script."
- Point 2 (future): "Today I'll finish the migration script and pick up that code review."
- Point 3 (blocker): "No blockers — I'm waiting on some feedback, but it's not urgent."
Why this works: the headline test discards the process ("trying to figure out why it was failing," "a little bit," "didn't really finish") and keeps only the verifiable result. Three short sentences cover the same ground as the original paragraph in a fraction of the time.
Exercise 2 — Build a complete blocker. You have this situation: you can't move forward because you don't have access to the staging database, and you think the DevOps team handles that kind of access, but you don't know exactly who to ask. Write the blocker report with the lesson's three parts (what's holding you back, who/what resolves it, what you're asking for), not just "I'm blocked."
See solution
Something like: "I'm blocked on staging DB access — I think DevOps owns that, but I'm not sure who exactly. Could someone point me to the right person?"
- What's holding you back: staging DB access.
- Who resolves it: DevOps (even if you don't know the exact name, naming the team is already useful information).
- What you're asking: a concrete, bounded request ("point me to the right person"), not a generic "help me."
Why this works: it turns an "I'm blocked" that leaves the team guessing into an action someone can take right then, which is exactly what point 3 of the standup needs.
Exercise 3 — Spot the antipattern. Each of these four sentences has a different mistake from the "Common mistakes and how to avoid them" table. Identify which one it is and fix it in one sentence.
- "Sorry, I know I should have done more, sorry, I just— sorry, I'll try to catch up."
- "I'm blocked." (and silence)
- "So basically what happened was I opened the file, and then I saw the variable was undefined, and then I checked like three other files, and then I..."
- "So about that bug — actually wait, let's see, maybe the issue is in the config file, let me check right now while everyone's here..."
See solution
- Over-apologizing. Fix it: "Yesterday didn't go as planned. Today I'm back on it."
- Blocker with no request. Fix it: "I'm blocked on X, I need Y from Z."
- Narrating the whole day. Fix it: say the headline, "I fixed a bug with an undefined variable."
- Solving the problem in the standup. Fix it: "Let's take it offline."
Why this works: every antipattern has a one-sentence fix because the problem is never vocabulary — it's format discipline: less apology, more request, less narration, less live problem-solving.
Exercise 4 — Your slow day, honest and with a plan. Think of a real day (or a plausible one) when you didn't make the progress you expected. Write your full three-point standup following the lesson's rule: honest about the past in one sentence, concrete about the plan in the next, without over-apologizing.
See solution
There's no single correct answer; the solution is the structure, not the exact content. Check yourself against these three criteria:
- Does your point 1 say what happened in one sentence, without dressing it up or apologizing more than once?
- Is your point 2 a concrete plan for today, not a vague promise like "I'll try harder"?
- If you're still on the same thing as yesterday, did you ground it with something like "the tricky part is X, and I expect to finish that today" instead of repeating a bare "I'm still working on it"?
An example that meets all three: "Yesterday didn't go as planned — I got pulled into a production issue. Today I'm back on the caching work, and the tricky part left is the invalidation logic, which I expect to finish today."
Why this works: it cleanly separates the fact (past, one sentence, no excuse) from the plan (future, concrete, grounded), which is exactly what distinguishes someone in control from someone lost.
What you're taking with you
The daily standup is your first speaking win in English, and it's no small thing: it's the shortest, most predictable, and most repeated situation you're going to find, and that makes it the best place in the world for the muscle to start loosening up. You have a fixed three-point format that never changes, a phrase bank for each one, a way to report a blocker in twenty seconds while asking for something concrete, and a plan for the days you didn't make progress that makes you look mature instead of lost. And you have a practice routine — scripted first, unscripted after, always recording yourself — that runs on the cadence you already set.
What comes next is harder, and it rightly comes after: in lesson 4 we move from your prepared monologue to the real back-and-forth of a meeting, where several people talk, interrupt each other, and you have to learn to take and hold the floor without getting left out. But you face that already warmed up. The standup was the warm-up; and a good warm-up is half the game.
Before moving on, you should be able to:
- Say your full standup turn in under thirty seconds, with a clear headline for the past and the future.
- Report a blocker in twenty seconds with its three parts: what's holding you back, who or what resolves it, and exactly what you're asking for.
- Recognize at least two of the antipatterns from the table above (narrating the whole day, blocker with no request, over-apologizing) and fix them on the spot.
- Report a day with no progress by being honest in one sentence and concrete about the plan, without sounding lost or over-apologizing.
If any of those points still feels forced, repeat phase 1's timed practice before moving on to lesson 4: from there on, you won't have a script to fall back on.
Resources
- The Scrum Guide — Daily Scrum — the official definition of the event: what questions it answers, how long it lasts, and what it's for. It's the primary source behind this lesson's three-point format.
- Standups for agile teams (Atlassian) — Atlassian's practical guide on running an effective standup, with the same antipatterns (meetings that drag on, solving problems live) seen from the team's side.
- YouGlish — search phrases like "I'm blocked on," "let's take it offline," or "I'll pick up" and hear them said by real speakers on video. Useful for this lesson's unscripted practice phase.
- Wiktionary — wrap up — definition of the phrasal verb used in point 1's phrase bank ("I wrapped up the migration script"), with usage examples in context.