Read 5 simulated standup transcripts and answer comprehension questions. Practise identifying blockers, status updates, team dynamics, and sprint vocabulary.
How to use these transcripts
Read the transcript carefully — note who is speaking and what they report
Look for the three standup questions: Yesterday / Today / Blockers
After answering, read the explanation to learn key vocabulary
Try reading the transcript aloud — it builds fluency for real meetings
0 / 5 completed
1 / 5
📄 Transcript
Lena (Scrum Master): "Good morning everyone. Let's keep it quick — what did you do yesterday, what's today, any blockers? Alex, you're first."
Alex (Backend): "Yesterday I finished the API endpoint for user profile updates. Today I'm starting on the notification service. No blockers."
Lena: "Great. Maria?"
Maria (Frontend): "I was working on the dashboard filters. Today I'll continue — but I'm blocked. The API spec for the filter endpoint still hasn't been updated. I can't finish without it."
Lena: "Noted. Alex, can you update the spec by noon?"
Alex: "Sure, I'll add that to my morning."
Lena: "Thanks. Sam?"
Sam (QA): "Yesterday I wrote test cases for the login flow. Today I'll run regression on the profile update. No blockers."
Who is blocked in this standup, and what is the reason?
Maria says: "I'm blocked. The API spec for the filter endpoint still hasn't been updated."
Standup blocker vocabulary:
"I'm blocked" = something is stopping my progress
"I'm waiting on [person/thing]" = same meaning, more specific
"No blockers" = nothing is stopping me
"At risk" = a potential blocker, not yet blocking but could be
Notice how blockers are handled: Lena immediately turns to the relevant person (Alex) and asks for resolution with a time ("by noon"). This is the standup format working correctly — surface blockers, resolve them offline or immediately.
2 / 5
📄 Transcript
[Remote standup via video call. Three participants.]
Priya (Tech Lead): "OK, sprint day 7. Raj, you were working on the auth refactor?"
Raj: "Yeah, pushed the changes yesterday. PR is up for review — it's a big one, about 400 lines. I'd actually appreciate a second reviewer if anyone has bandwidth."
Priya: "I can take a look this afternoon. James, how about the mobile push notifications?"
James: "Still in progress. I hit an issue with Firebase on Android 12 — the payload structure changed. I need another day to work around it. So my estimate was Wednesday, but I'm pushing it to Thursday."
Priya: "OK, flag me if you get stuck. Any risks for the Friday release?"
James: "Low. The feature is non-critical and behind a flag."
Raj: "I'm good if reviews come in today."
Why is James revising his delivery estimate from Wednesday to Thursday?
James says: "I hit an issue with Firebase on Android 12 — the payload structure changed."
Key standup patterns from this dialogue:
Estimate revision: "My estimate was Wednesday, but I'm pushing it to Thursday" — honest, proactive communication with a new date
Risk mitigation: "The feature is non-critical and behind a flag" — Priya asks about release risk; James answers with impact assessment
Requesting help: "I'd appreciate a second reviewer if anyone has bandwidth" — Raj uses "bandwidth" (available time/capacity) to phrase the request softly
Standup vocabulary:
"behind a flag" = behind a feature flag — can be disabled if needed
"have bandwidth" = have free capacity to take on more work
"non-critical" = not essential for the release to succeed
"pushing it to [day]" = revising the deadline later
3 / 5
📄 Transcript
[Sprint review standup. Team of 5.]
Scrum Master (Tom): "We're on the last day of the sprint. Let's do a quick status round before the review meeting. Carla?"
Carla (Backend): "I finished the data export feature and it's in staging. Tested and passing. Ready for review."
Tom: "Good. Dan?"
Dan (Frontend): "I'm done with the settings page UI. But I found a visual regression in the notification bell — it's a quick CSS fix, 30 minutes top. I'll push it before we demo."
Tom: "Can you commit to that? The demo starts at 2."
Dan: "Absolutely. I'll have it done by 1:30."
Tom: "Great. Nina?"
Nina (QA): "I completed test coverage for Carla's feature — 47 test cases, all passing. I also found a low-priority bug in the user settings form — filed it as a backlog item, not a blocker."
Tom: "Perfect. Sprint's looking good for closure."
What does Dan say he found during the sprint, and how does he plan to deal with it before the demo?
Dan says: "I found a visual regression in the notification bell — it's a quick CSS fix, 30 minutes top. I'll push it before we demo."
Key vocabulary in this standup:
"visual regression" = an unintended visual change from a code update (something that used to look right now looks wrong)
"in staging" = deployed to the staging/test environment (not yet in production)
"backlog item" = a task recorded for future sprints, not the current one
"sprint closure" = formally ending the sprint
Notice Nina's professional move: She found a bug but classified it as "low-priority, not a blocker" and filed it in the backlog. This shows judgment — not everything needs to block the sprint, and communicating the classification is part of QA's communication skill.
4 / 5
📄 Transcript
[End-of-sprint standup. Focus on velocity.]
Lead Dev (Sophie): "Last item before we wrap — velocity. We committed to 34 points this sprint. Ben, what did we actually deliver?"
Ben (PM): "We shipped 28. Six points slipped: the email digest feature moved to next sprint — the third-party integration took longer than estimated."
Sophie: "So about 82% velocity. Not bad, but the email digest pushed twice now. We should probably spike on the integration in the planning session."
Ben: "Agreed. I'll add a tech spike to the backlog for that. One hour scoped."
Sophie: "Good. Also — we had one incident this sprint. Sam?"
Sam (DevOps): "Yeah, a 12-minute outage Tuesday caused by a config deployment without rollback. I'm adding a rollback verification step to our deploy checklist. It's a process fix, not a code fix."
Sophie: "Thanks Sam. OK — retrospective in 10 minutes. See you there."
In this standup, what is meant by "velocity" and what does it mean that they achieved 82% velocity?
Velocity = story points delivered per sprint (28 of 34 = 82%)
Agile/Scrum vocabulary from this dialogue:
"velocity" = the amount of work (story points) a team delivers per sprint. Used to predict future capacity.
"story points slipped" = planned story points not delivered in the sprint (moved to next sprint)
"tech spike" = a short, timeboxed piece of research or prototyping to reduce uncertainty before estimating a feature
"scoped" = "one hour scoped" means it has a defined time limit
"rollback" = reverting a deployment to a previous version after a problem
Important: Ben says the email digest "pushed twice now" — the team recognizes a pattern of slippage and proposes a structural fix (a spike) rather than just guessing again.
5 / 5
📄 Transcript
[Distributed team standup across 3 time zones. London, Warsaw, Singapore.]
Ava (London, Team Lead): "Quick reminder — async standups via Slack are fine for non-critical days, but let's do a sync call on Mondays. Today's Tuesday so this is async — I'll just read out the updates. From Jamie in Singapore: 'Completed the data pipeline refactor. Starting on caching layer. No blockers but I want eyes on my schema design — will post in #dev-review.' From Marta in Warsaw: 'PR #223 is ready for review. I'll be OOO Thursday afternoon, back Friday.' From myself: 'In product meetings all morning, available from 1 PM London. Our retrospective is Thursday at 4 PM London / 5 PM Warsaw / 11 PM Singapore. I'll record it for Jamie.'"
What does Jamie request, and how does the team handle timezone challenges according to this standup?
Jamie requests a schema design review ("I want eyes on my schema design — will post in #dev-review") and the team uses async standups + recordings to bridge time zones.
Key distributed team vocabulary:
"async standup" = written updates posted in Slack/Teams instead of a live meeting
"sync call" = a real-time meeting where everyone is live simultaneously
"OOO" = Out Of Office
"want eyes on [something]" = want someone to review or check it
"I'll record it" = the pragmatic solution to covering 11 PM for Singapore
Best practices shown:
Clearly stated availability: "available from 1 PM London"
Meeting times in multiple zones: "4 PM London / 5 PM Warsaw / 11 PM Singapore"
OOO flagged in advance: "OOO Thursday afternoon, back Friday"