Agile English Vocabulary: Sprint Planning, Retrospectives, Story Points, and Velocity
A practical English guide for Agile and Scrum practitioners — how to speak in sprint planning, lead retrospectives, discuss story points, and talk about velocity in English.
Understanding Agile vocabulary is one thing; being able to speak it fluently in a standup, planning session, or retrospective is another. Many developers who understand the concepts struggle to express them naturally in English — they hesitate when estimating, speak vaguely in retrospectives, or miss nuances in planning discussions. This guide goes beyond definitions to give you the exact phrases and conversation patterns you need for each Agile ceremony.
Sprint Planning Language
Sprint planning is the meeting that kicks off each sprint. Its purpose is to agree on what the team will deliver. The language used is specific and purposeful.
Discussing the Sprint Goal
The sprint goal is discussed at the start of planning. Useful phrases:
- “The proposed sprint goal is to deliver the user authentication flow end to end.”
- “I’d suggest we refine the goal — as written, it’s too broad for a two-week sprint.”
- “Does this goal align with the Q2 roadmap priorities?”
- “If we only achieve one thing this sprint, what should it be?”
Committing to Work
When the team selects items from the backlog, they commit to completing them. Language around commitment:
- “I’m comfortable committing to this story — the requirements are clear.”
- “I’m hesitant to commit to this one. I have some technical uncertainty around the database migration.”
- “We’re overcommitting — based on our velocity, we have capacity for about 30 points and we’ve selected 42.”
- “Can we move this to the icebox and revisit it next sprint?”
Icebox / Backlog Vocabulary
Icebox — items deprioritised and unlikely to be worked on soon. “That idea is interesting but let’s put it in the icebox for now.”
Groomed backlog — a backlog where items have been reviewed, estimated, and ordered. “The backlog is well-groomed — planning should go quickly today.”
Ready for development — a story that has been fully refined: acceptance criteria written, dependencies identified, and estimate agreed. “This story isn’t ready for dev — we still need to confirm the design.”
Story Pointing and Estimation Language
Estimation is one of the most linguistically rich parts of Agile. Teams use various scales and have strong opinions about how to estimate.
Planning Poker Phrases
Planning poker is a common estimation technique where each team member independently selects a point value and reveals simultaneously.
- “Let’s play planning poker on this story.”
- “Everyone reveal on three — one, two, three.”
- “We have a wide spread: 3, 5, 8, and 13. Let’s discuss.”
- “Why did you go with 13? I was thinking 5.”
- “I went high because I’m accounting for the unknown — we’ve never integrated with this vendor’s API before.”
- “I went low because this looks similar to the email notification feature we built in sprint 8.”
Common Estimation Phrases
“I need more information before I can estimate this.” — Asking for clarification before pointing.
“This is a spike, not a story — we should timebox it rather than point it.” — Identifying when a task is research, not implementation.
“The complexity here is in the edge cases, not the happy path.” — Explaining why an apparently simple story has a high estimate.
“I think we’re overthinking this — it’s a 2.” — Anchoring toward a lower estimate.
“Let’s split this — the backend and frontend work should be separate stories.” — Proposing to break a large story into smaller ones.
Retrospective Phrases
The retrospective is where teams reflect on their working process. Facilitation language and participant language are both important.
Facilitator Language
The Scrum Master or facilitator opens and structures the retro:
- “Let’s start today’s retrospective. We have 45 minutes.”
- “Our focus today is on our PR review process — we had some blockers this sprint because of slow reviews.”
- “I’d like everyone to add sticky notes to three columns: What went well, What could be improved, and Action items.”
- “Let’s dot-vote on these — you each have three votes. Mark the items you most want to discuss.”
- “We’ve identified five items. We only have time for three. Which should we prioritise?”
- “Before we close, let’s confirm our action items: who, what, and by when.”
Participant Language
Team members participating in a retro use a different register — more personal, reflective, and forward-looking:
- “What worked well for me this sprint was the pair programming sessions — they unblocked me twice.”
- “Something I struggled with: the acceptance criteria were unclear on two stories, which led to rework.”
- “I think we should change how we handle PRs — if a PR is open for more than 24 hours, the author should ping the channel.”
- “I’d push back on that — the problem isn’t the process, it’s that we’re understaffed on reviewers.”
- “That’s a fair point. Can we agree on a specific action rather than just ‘improve reviews’?”
- “I’d like to take ownership of the action item to draft a PR review SLA.”
The Four-Format Retrospective
Many teams use the “four Ls” retrospective format: Liked, Learned, Lacked, Longed for.
- Liked: “I liked how we handled the production incident — the team coordinated really well.”
- Learned: “I learned that our test suite doesn’t cover the edge case we hit in production — we need more integration tests.”
- Lacked: “We lacked visibility into the dependencies between our work and the infrastructure team’s work.”
- Longed for: “I longed for better documentation on the legacy payment module — I spent two days reverse-engineering it.”
Velocity and Capacity Discussions
Velocity — average story points completed per sprint. Velocity is descriptive, not prescriptive.
- “Our velocity over the last six sprints averages 28 points.”
- “Velocity dropped to 18 this sprint because of the production incident on Thursday.”
- “We shouldn’t set velocity as a target — it’s a measurement, not a goal.”
- “Based on our velocity, we can estimate the remaining 140 backlog points will take about 5 sprints.”
Capacity — the total available working time for the sprint, accounting for holidays, meetings, and other commitments.
- “Our capacity this sprint is lower than usual — two team members are on leave.”
- “I’m at 70% capacity this sprint — I have two days of on-call duties.”
- “We should account for the company all-hands taking up half a day on Wednesday.”
Burndown chart — a graph showing remaining work vs. time within a sprint.
- “The burndown chart shows we’re trending above the ideal line — we may not finish all stories.”
- “The burndown is flat for three days — do we have a blocker we haven’t surfaced?”
Daily Standup Language
The standup is a brief daily sync. The classic three-question format generates specific language patterns:
Yesterday: “Yesterday I finished the API integration for the search feature and opened a PR.”
Today: “Today I’m going to work on the frontend for the same feature. I’m planning to pair with Oksana this afternoon.”
Blockers: “I don’t have any blockers.” / “I’m blocked waiting for credentials from the DevOps team — I flagged it in the ops channel yesterday but haven’t heard back.” / “I have a potential blocker: the library we planned to use has a bug in the latest version. I’ll investigate this morning and let you know.”
Practical Exercises
-
Standup simulation: Write three days’ worth of standup updates for a fictional feature you are building. Use the Yesterday / Today / Blockers format. Vary the language — do not repeat the same sentence structures.
-
Retrospective role play: With a colleague, practise a 20-minute retrospective. Alternate facilitating. Record it and review the vocabulary and phrases used.
-
Estimation dialogue: Practise planning poker by choosing five open GitHub issues in any public repository. Estimate each one independently, then explain your estimates in English — focus on using vocabulary like complexity, edge cases, uncertainty, similar to, and spike.
-
Velocity calculation: Given a fictional team’s last six sprint results (20, 24, 18, 30, 26, 22 points), calculate the average velocity and write a one-paragraph sprint capacity plan for the next sprint, accounting for two team members being 50% available.
Practise Agile vocabulary with the dedicated Agile and Scrum exercises on Coders Lingo.