Sprint Planning

Sprint Planning is the moment where business priorities meet team capacity. It's a meeting where the Product Owner says "here's what we need to build" and the team says "here's what we can realistically finish in 2 weeks." Get this right and the sprint flows smoothly. Get it wrong and you have an overcommitted team burning out or an undercommitted team with nothing to do.

What Sprint Planning Is

Sprint Planning answers three questions:

• What is the sprint goal? What is the one main thing we're trying to achieve?
• What work will we pull into this sprint to achieve that goal?
• How will we break down each piece of work into tasks that developers can complete?

It typically happens at the start of a sprint (Monday morning, for a 2-week sprint starting Monday) and lasts 2–4 hours depending on team size. The Product Owner facilitates, the team discusses, and everyone leaves with a shared understanding of what gets built this sprint.

Backlog Refinement: Prep Work

Good sprint planning requires prep. That prep work is called backlog refinement (or backlog grooming). This usually happens a few days before the sprint planning meeting—without the whole team, so it doesn't burn everyone's time.

In refinement, the Product Owner and a few developers (or a tech lead) walk through items at the top of the backlog:

• Clarify what needs to be built: What does success look like? What's in scope and what's not?
• Break down big items: A feature that takes 3 weeks needs to be broken into smaller stories that fit in one sprint
• Estimate effort: Developers give a rough estimate of complexity
• Surface questions: If there's ambiguity, raise it now, not during sprint

Refinement is where you prevent planning meetings from becoming design sessions. By sprint planning, the work is scoped and questions are answered. The team can focus on committing to a realistic workload.

Story Points vs Time Estimates

Here's a key difference in how Agile teams work. Don't estimate in hours. Estimate in story points.

Story points measure complexity and uncertainty, not literal hours. A "simple" 1-point story takes maybe 4 hours. A "complex" 5-point story might take 16 hours or 2 days—you don't know exactly. A 13-point story is so complex you don't really know how long it'll take, so it needs to be broken down.

Why? Because estimating hours feels precise but isn't. You write "6 hours to build the login form" and somehow it takes 12 hours because edge cases emerge, design decisions are unclear, the API isn't ready. If you estimate points instead—"2 points because it's straightforward"—you accept the uncertainty upfront. Over time, you learn that your team delivers about 25 points per sprint. That's your velocity.

Most teams use a Fibonacci-like sequence for points: 1, 2, 3, 5, 8, 13. The gaps widen because as complexity grows, accuracy drops. You can't tell the difference between 7 hours and 8 hours (both are "1 day"), but you can tell the difference between "small and simple" (2 points) and "medium and kinda complex" (5 points).

Velocity: Your Delivery Gauge

Velocity is the number of story points a team completes in a sprint. It's your team's speed. If your team finishes 20 points per sprint on average, that's your velocity.

Why does it matter? Because it tells you how much to commit to in future sprints. If velocity is 20 points, plan for 20 points (or a bit less for safety). If you plan for 40 points because you're ambitious, the team will thrash and burn out.

Velocity stabilizes over time (usually 3–4 sprints). New teams have erratic velocity because they're learning the codebase, the tools, and the team processes. A maturing team has stable velocity, which makes forecasting easier. "We have 100 points of work remaining and deliver 20 points per sprint, so we'll be done in 5 sprints."

Important: Velocity isn't a measure of individual productivity. It's a team metric. A velocity of 15 for one team and 25 for another doesn't mean one team is lazy and the other is great. They might have different project complexity, team size, or estimation standards. Velocity is only useful for comparing a team to itself over time.

Sprint Goal: The North Star

At the start of planning, the Product Owner should articulate a sprint goal: a single sentence or short paragraph explaining the main outcome for the sprint. Not a feature list—a goal.

Examples:

• "Enable users to sign up with Google so we reduce signup friction"
• "Stabilize the payment processing so we reduce failed transactions"
• "Build the foundation for multi-tenant deployments for future SaaS scaling"

A sprint goal keeps the team focused. It explains why the work matters. It also helps with mid-sprint trade-offs. If a new request comes in and you ask "does this help us achieve the sprint goal?" and the answer is no, it waits for the next sprint.

Capacity Planning

Velocity tells you historical output. But you also need to account for what's happening this specific sprint. That's capacity planning.

Before planning, ask:

• Is anyone on vacation? (Reduce capacity by their percentage.)
• Are there planned meetings or offsite? (Account for that time.)
• Is anyone split across multiple teams? (They can't commit full time.)
• Do we need to allocate time for support/bug fixes? (Most teams do.)

Example: Your team's velocity is 25 points. But this sprint, two people are out for 3 days each, and you've allocated 20% capacity to support tickets. So your available capacity is roughly 25 × (1 − 0.2 − 0.15) ≈ 16 points. Commit to 15–16 points, not 25.

What Goes Into a Sprint

In sprint planning, the team pulls items from the backlog until they reach their capacity. What are good candidates?

• User stories: "As a user, I want to do X so that Y." These describe features from the user's perspective.
• Technical tasks: "Upgrade the database library" or "refactor the auth module." These don't directly deliver user value but they unblock future work.
• Bugs: Issues from the previous sprint or production bugs. Most teams allocate 20–30% of capacity to bugs; the rest to new features.
• Debt paydown: Planned refactoring to improve code quality or performance. This competes with features for capacity.

Breaking Down Stories Into Tasks

At the end of planning, each story should be broken into tasks—concrete pieces of work a developer can finish in a day or half-day. This prevents ambiguity and makes progress visible.

Example story: "Users can reset their password" (5 points)

Tasks:

• Create the password reset request endpoint (backend)
• Send reset email with token (backend)
• Build reset form UI (frontend)
• Validate reset token and update password (backend)
• Test the flow end-to-end
• Write automated tests for the endpoint

Each task is 4–8 hours of work. A developer picks a task, finishes it, and picks another. Progress is visible—"we've completed 4 of 6 tasks for this story" is more informative than "we're 50% done."

Sprint Planning Anti-Patterns

Overcommitting: The team gets ambitious and commits to 40 points when velocity is 20. They burn out, quality suffers, and the next sprint is chaos because they're still fixing last sprint's bugs.

Under-specifying: Stories go into the sprint fuzzy and undefined. Developers waste time clarifying on the fly, or worse, they build the wrong thing.

Skipping refinement: Backlog refinement feels like duplicate work to people new to Agile. So teams skip it, and sprint planning becomes a 6-hour design session while developers sit idle.

The Product Owner's Role

In sprint planning, the Product Owner:

• Presents the sprint goal and the prioritized backlog items
• Answers questions about what "done" means for each story
• Accepts or rejects completed work at the end of the sprint
• Makes trade-off decisions ("should we do feature A or B?")

The Product Owner doesn't assign tasks or dictate how to build things. They define the outcomes, and the team figures out the how.

Definition of Ready vs Definition of Done

Teams often define two important standards:

How Planning Changes as Teams Mature

New teams spend a lot of time in planning—2–4 hours per 2-week sprint. They need to discuss everything, clarify scope, and estimate carefully. They also have unpredictable velocity because they're learning.

Mature teams get faster. Planning might shrink to 1–2 hours because they know their codebase, they have patterns for estimation, and they trust each other. They also have stable velocity, so forecasting is easier—"we can take in 23 points this sprint" is a quick decision.

Some very mature teams simplify even further. They stop estimating in points and instead estimate in "days of work" or just commit to "all items in this milestone." This works if the team is stable and the product is mature.

The Ripple Effect

Good sprint planning cascades through the entire sprint. The team knows what to build and why. The Product Owner knows what to expect. There are no mid-sprint surprises or scope creep because the backlog is prioritized and the sprint goal is clear.

Bad planning creates friction everywhere—developers are confused, priorities keep changing, the sprint goal is fuzzy, and things don't ship because they weren't ready.

The next section covers Git Workflow—how developers collaborate on code and use version control to stay synchronized.