Read 3 transcripts from Agile ceremonies — sprint planning sessions and a retrospective. Answer comprehension questions and learn the vocabulary of software delivery.
Core Agile ceremony vocabulary
Sprint planning: the team selects stories from the backlog and commits to delivering them in the sprint
Sprint review: the team demos what was delivered to stakeholders
Retrospective (retro): the team reflects on process and agrees improvements
Definition of Done (DoD): the checklist a story must pass to be "done"
0 / 3 completed
1 / 3
📄 Transcript
[Sprint Planning Meeting — Day 1 of Sprint]
Product Owner (Lisa): "OK, we've got 34 points of capacity this sprint. Let's walk through the backlog. First up: user-story US-47 — 'As a user, I want to reset my password via email.' Eight points. Any questions before we commit?"
Dev Lead (Tom): "I have a concern. The current email service is rate-limited. If we get a lot of password resets at once, we might hit the limit. Should we add a task for graceful error handling?"
Lisa: "Good catch. Let's add a subtask. Dev team — what's the estimate for the error handling?"
Developer (Raj): "Two points, maybe three."
Lisa: "Let's say three. So US-47 is now eleven points. That still fits. Moving on — US-52: 'Add dark mode support.' Thirteen points. Who wants this one?"
Frontend Dev (Mia): "I can take it. I already did a spike on it last sprint — we'll use CSS custom properties without a new library."
Lisa: "Perfect. That leaves ten points. US-61: 'Fix pagination on the search results page.' Five points and US-68: 'Migrate user avatars to CDN.' Five points. Can we fit both?"
Tom: "Yes — those are small and independent. I'd do pagination first since it's been in the backlog four sprints."
What was the concern Tom raised about US-47, and how was it resolved?
Tom says: "The email service is rate-limited — if we get a lot of password resets, we might hit the limit."
Key sprint planning vocabulary from this transcript:
"capacity" = the total story points a team can deliver in a sprint (based on team size and availability)
"user story" = a feature described from the user's perspective: "As a [user], I want to [action] so that [benefit]"
"subtask" = a smaller piece of work added under a main story
"estimate" = the story point value the team assigns to a task
"spike" = a timeboxed research task to reduce uncertainty (Mia mentions one from the previous sprint)
Good planning behaviour: Tom proactively flagged a risk before committing. This is how good engineers add value in planning — not just building, but thinking about failure modes.
2 / 3
📄 Transcript
[Sprint Retrospective — End of Sprint 23]
Scrum Master (Ana): "Standard format — Start, Stop, Continue. What should we start doing?"
Dev 1 (Kris): "Start: proper PR descriptions. I keep reviewing PRs with no context. I have no idea what the ticket was about."
Dev 2 (Yuki): "I agree. Also — start running load tests before releasing to staging, not after."
Ana: "Good. What should we stop doing?"
Kris: "Stop holding unplanned calls during deep work hours. We had three surprise meetings this sprint that killed my flow."
PM (Ben): "Noted. I'll try to consolidate feedback into scheduled slots."
Ana: "What should we continue?"
Yuki: "Continue the Friday knowledge-sharing sessions. They've been really useful — I learned about the new query optimiser from Sam's session last week."
Ana: "Agreed. OK, let's pick action items. Kris, can you own adding a PR template to the repo? Yuki — document the load test process. Ben — add a 'meeting free' block to the team calendar?"
[All agree.]
What is the "Start, Stop, Continue" format, and what concrete action items did the team agree on?
Start/Stop/Continue is a classic retrospective technique for structured team improvement discussions.
The three categories:
Start: things the team should begin doing
Stop: things the team should stop doing because they're harmful or unproductive
Continue: things that are working well and should be maintained
Good retrospective practice shown here: Every discussed issue was converted to a concrete, assigned action item with an owner. This is the critical step that makes retros actionable rather than just venting sessions.
"load tests" = tests that simulate high traffic volume to check system behaviour under stress
"flow" = "deep work flow" — state of uninterrupted concentration (from psychology)
"knowledge-sharing sessions" = internal team presentations to spread expertise
3 / 3
📄 Transcript
[Combined Sprint Planning + Retro — Agile team at a scale-up]
Scrum Master (Dan): "Before we plan sprint 31, let's close sprint 30 properly. Highlights: we delivered 29 of 32 committed points. The session service encryption task is carrying over — the third-party SDK had a breaking change that wasn't in the changelog. Anyone want to add to the sprint review notes?"
Senior Dev (Petra): "Just one thing — we should document the SDK issue. Next time we onboard a third-party SDK, we run a spike in an isolated branch first."
Dan: "Agreed. I'll add that to our engineering standards doc. OK, retrospective results — the team voted on two items. First: definition of done needs to include a passing security scan, not just passing unit tests. Second: we want explicit 'parking slots' in planning for carry-over items."
PM (Cass): "On the security scan — do we have tooling for that?"
Petra: "Snyk is already in the pipeline. We just need to make the job blocking, not advisory."
Dan: "Let's add a task to sprint 31 to configure that. One point, Petra owns it. Now for planning..."
What does "definition of done" mean, and what change did the team decide to make to theirs?
Definition of Done (DoD) = a shared checklist that a story must pass before it's considered truly "done"
Common items in a DoD include:
Code written and peer-reviewed
Unit tests passing
Integration tests passing
Acceptance criteria met
Documentation updated
Deployed to staging
The team here adds: passing security scan — not just unit tests.
Why this matters: Without an explicit DoD, "done" is ambiguous. "Done done" is a common phrase used when emphasising that something fully meets the DoD, not just "the code works on my machine."
Key vocabulary:
"breaking change" = an update that makes previously working code stop working
"changelog" = a file documenting what changed in each version of a library/product
"blocking job" = a CI/CD pipeline job that stops the build if it fails (vs. "advisory" = warns but doesn't block)
"carry-over" = a story not completed in the planned sprint, moved to the next one