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.