English Phrases for Sprint Planning Sessions

Sprint planning is one of the most language-intensive ceremonies in the agile process. You need to discuss estimates, negotiate scope, ask clarifying questions, and reach collective decisions — often under time pressure. Having a reliable set of phrases for these conversations makes them faster and more productive.

This guide covers the English you need for every phase of a sprint planning session.

Opening the Sprint Planning Session

The Scrum Master or facilitator typically opens the session and sets the context.

“Let’s get started. The sprint goal I’d like to propose is to complete the user authentication flow end-to-end. Does that sound right to everyone?” “Before we pull stories in, let’s confirm our team capacity for this sprint.” “Today’s agenda: capacity check, sprint goal, then we’ll pull stories from the top of the backlog.”

Capacity Planning Language

Checking Availability

“How many days is everyone available this sprint? We have a bank holiday on Monday.” “[Name], you mentioned you’re at a conference on Thursday and Friday — so you’re at 6 days capacity?” “If we account for the team holiday and the two days of onboarding sessions, our effective capacity is around 28 story points, down from our usual 36.”

Vocabulary

• Capacity — the team’s available working time in a sprint, often expressed in points or ideal days
• Velocity — the average number of story points a team completes per sprint (based on historical data)
• Sprint capacity — the portion of velocity adjusted for the specific sprint’s availability

“Our average velocity over the last six sprints is 34 points. With 80% capacity this sprint, I’d suggest we pull in around 27 points.”

Backlog Refinement Phrases

Discussing Story Readiness

“Is this story ready? Do we have everything we need to start work on it?” “The acceptance criteria on this one are a bit vague — before we estimate it, can we clarify what ‘the user can filter results’ actually means?” “This story has a dependency on the API team. Have we confirmed they’ll have the endpoint ready by the second week of the sprint?”

Splitting Stories

“This story feels too big for one sprint. Can we split it into two parts?” “What’s the minimum we need to deliver to get value from this? Can we defer the edge cases to a follow-up story?” “Let’s break this into a backend story and a frontend story — they can be worked in parallel.”

Story Pointing

Running the Estimation

Story pointing is typically done using Planning Poker or a similar technique, where team members simultaneously reveal their estimates to avoid anchoring.

“Let’s point this story. Everyone think about it for thirty seconds, then we’ll reveal simultaneously.” “We have a spread — [Name] said 3, [Name] said 8. Can we hear the reasoning from both sides?” “The main uncertainty for me is whether we need to change the database schema. If yes, it’s an 8; if not, it’s a 3.”

Common Estimation Scales

Most teams use a Fibonacci-like scale: 1, 2, 3, 5, 8, 13, 21.

“Anything above a 13 is probably too big to fit in a sprint — let’s split it.” “If there’s too much uncertainty to estimate, we should run a spike first.”

When the Team Disagrees

“We have a split — can we discuss what’s driving the high estimate?” “Is the complexity difference because of the integration testing, or is it the implementation itself?” “Let’s do a quick re-point after the discussion.”

Negotiating Sprint Scope

Pulling Stories In

“We have room for a few more points. Are there any small stories at the top of the backlog we can pull in?” “I’d like to pull in the accessibility fix — it’s only a 2 and it’s been waiting three sprints.”

Pushing Stories Out

“I don’t think we can commit to this one in addition to everything else. Can we move it to the next sprint?” “Let’s be realistic about capacity — we’re already at our velocity target. Pulling in more risks spillover.” “I’d rather under-commit and over-deliver than the other way around.”

Handling Unplanned Work

“We should leave a buffer for unplanned work — I’d suggest reserving 10-15% of capacity.” “Based on last sprint, we had about 5 points of unplanned support work. Let’s account for that.”

Defining the Sprint Goal

The sprint goal is a single, concise statement of what the team aims to achieve by the end of the sprint. It gives the team a shared focus and helps when making mid-sprint scope decisions.

“Can we articulate the sprint goal in one sentence? Something like: ‘By end of sprint, users can register, log in, and reset their password.’” “The sprint goal should describe the outcome, not just list the stories. What value are we delivering?” “If we had to cut scope mid-sprint to protect the goal, which stories are essential and which are nice-to-have?”

Closing the Session

“Let’s do a final commitment check — does everyone feel confident we can complete everything we’ve pulled in?” “Are there any blockers or dependencies I should capture before we close?” “Sprint goal is set, stories are pointed and committed. Let’s have a great sprint.”

Effective sprint planning language is direct, collaborative, and focused on outcomes. The phrases in this guide will help you participate fully — whether you are the Scrum Master running the session or a developer contributing estimates and scope decisions.

Navigating Nuance: Addressing Potential Misunderstandings

As a non-native speaker, you’ll quickly discover that even seemingly straightforward requests in a technical environment can be loaded with subtle nuances of English. It’s not just about what you say; it’s about how you say it and the implied expectations surrounding your contribution. Let’s look at a scenario commonly encountered during code reviews – specifically, when addressing feedback on a pull request.

Imagine Sarah, a senior developer, leaves a comment on David’s PR: “This needs more tests.” While technically accurate, this statement can feel vague and potentially discouraging. It doesn’t convey why more tests are needed or what kind of tests would be beneficial. A more constructive approach, incorporating phrases you might hear in professional settings, would be something like: “David, could you elaborate on the areas where we’re seeing increased risk? Perhaps adding unit tests around the new API endpoint and integration tests to cover the data flow would strengthen this PR.” Notice the use of “could you elaborate” – a polite request for clarification – and framing the suggestion as an opportunity to improve the code, not a criticism. Using phrases like “strengthen this PR” is more positive than simply stating something needs fixing.

Another frequent situation arises in Slack channels when discussing sprint capacity. A team member might post: “Can we fit this in?” This begs the question – what does “fit” mean? It’s far better to be specific and proactive. Suggesting a phrase like, “Let’s assess its complexity against our remaining capacity for this sprint. Perhaps we can discuss breaking it down into smaller tasks if needed,” demonstrates an understanding of the planning process and invites collaboration. Remember, offering solutions alongside questions is almost always preferred. Don’t just point out problems; suggest how to address them.

Finally, be mindful of the language used in PR descriptions. A simple “Fixed bug” is insufficient. A better description might read: “Implemented a fix for intermittent data corruption during transaction processing. This involved refactoring the database connection logic and adding retry mechanisms as described in ticket #1234.” – clear, detailed, and referencing relevant documentation or tracking issues provides valuable context for reviewers.

# Example of using `git diff` to highlight changes - useful when discussing PRs
git diff --cached --summary

This command provides a concise summary of the changes included in your staged commits, which can be helpful during discussions about the scope of work being addressed. It’s a simple way to visually represent the difference between the current state and the proposed changes, facilitating clearer communication with team members.