Sprint Planning: Choosing Work and Building a Plan Around the Sprint Goal

What to Prepare Before Sprint Planning

Sprint Planning works best when the team arrives with a few essentials ready. As a new team member, your job is not to “have all the answers,” but to show up informed, ask clarifying questions early, and help the team turn a set of Product Backlog Items (PBIs) into a coherent plan that supports a single Sprint Goal.

Inputs You Should Expect (and How to Use Them)

• Ordered Product Backlog (top items are most likely candidates): You will plan from the top down. If an item is unclear, it is a signal to ask questions or reduce scope, not to guess.
• Team capacity for the Sprint: Capacity is the realistic amount of time/energy available after accounting for vacations, on-call, training, meetings, and other non-delivery work. Capacity is not a promise; it is a constraint for planning.
• Definition of Done (DoD): DoD is the quality bar that determines what “finished” means. During planning, DoD affects effort and sequencing (e.g., testing, documentation, reviews, security checks).
• Known constraints: Examples include fixed dates, dependencies, environment limitations, release windows, compliance checks, or key people being unavailable. Constraints shape what is feasible and how you slice work.

Quick Prep Actions for a New Team Member

• Read the top PBIs likely to be selected and note questions (acceptance criteria, edge cases, data needs, UX expectations).
• Check your availability and tell the team early (planned leave, on-call rotations, appointments).
• Scan recent technical context (recent changes, incidents, or refactors that might affect feasibility).
• Bring potential risks you already see (e.g., “integration with X is flaky,” “we don’t have test data”).

What Happens in Sprint Planning (Meeting Flow)

Sprint Planning aligns the team on why the Sprint matters (Sprint Goal), what will be delivered (selected PBIs), and how the work will be done (a plan). The meeting is collaborative: the team explores options, makes trade-offs, and leaves with a shared understanding.

1) Start with Constraints and Capacity

Before choosing work, make constraints explicit so you do not plan a Sprint that cannot happen.

• Confirm who is available and for how much of the Sprint.
• List known constraints (e.g., “staging environment unavailable Tuesday,” “security review required for auth changes”).
• Call out “must-do” operational work (e.g., support rotation, incident follow-ups).

Practical tip: If capacity is reduced, plan fewer PBIs rather than lowering quality. DoD stays the same.

2) Craft a Sprint Goal (Why This Sprint Matters)

A Sprint Goal is a short statement of the outcome the Sprint should achieve. It should be meaningful to stakeholders and useful for the team’s day-to-day decisions. It is not a list of tasks; it is the purpose that ties selected PBIs together.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Steps to Craft a Strong Sprint Goal

1. Identify the desired outcome: What user or business problem should be improved by the end of the Sprint?
2. Anchor it to measurable behavior: What will be different? Faster checkout? Fewer support tickets? Ability to complete a workflow end-to-end?
3. Keep it narrow enough to guide trade-offs: If the goal is too broad, it won’t help when you need to drop or swap scope.
4. Validate it against constraints: Ensure the goal is feasible given capacity and dependencies.
5. Phrase it as an outcome, not a to-do list: “Enable customers to reset passwords without contacting support” is better than “Build reset page + email + tests.”

3) Select PBIs Based on Value and Feasibility

Once the Sprint Goal is clear, the team selects PBIs that best support that goal while fitting within capacity and constraints. Selection is not “grab the next N items”; it is a deliberate choice that balances value, risk, and feasibility.

How to Select PBIs (Practical Step-by-Step)

1. Start with the top of the ordered backlog and ask: “Does this directly support the Sprint Goal?” If not, consider whether it is still necessary (e.g., critical defect) or should wait.
2. Check readiness for planning: Do we understand the intent, acceptance criteria, and major edge cases? If not, either clarify now or reduce scope to what is understood.
3. Assess feasibility: Consider dependencies, unknowns, and technical complexity. If feasibility is uncertain, plan a smaller slice or a risk-reduction item that still supports the goal.
4. Balance value with risk: Prefer pulling in items that deliver user-visible value early, and schedule riskier work early in the Sprint when possible.
5. Stop when you reach capacity: Leave room for the reality of the Sprint (collaboration, reviews, unexpected issues). Overfilling creates churn and mid-Sprint renegotiation.

Common Trade-offs You’ll See (and How to Participate)

• “We can’t fit everything.” Help by asking which PBIs are essential to the Sprint Goal and which are optional.
• “This item is too big.” Suggest splitting by workflow step, user segment, platform, or “happy path first.”
• “We’re unsure about X.” Propose a small spike, prototype, or thin vertical slice that reduces uncertainty while still moving toward the goal.

Decomposing Selected PBIs into a Plan (How We’ll Do the Work)

After selecting PBIs, the team decomposes them into actionable work. The goal is not to predict every detail, but to create enough clarity to start the Sprint confidently, coordinate work, and expose risks early.

What “A Plan” Looks Like in Practice

• Work breakdown: PBIs are decomposed into tasks that are small enough to complete within a day or two.
• Sequencing: Identify what must happen first (e.g., schema change before API update).
• Ownership and collaboration: Who will start what, where pairing is needed, and where reviews are required.
• DoD-aware tasks: Testing, documentation, monitoring, security checks, and release steps are included (not assumed).
• Risk notes: Known unknowns, dependencies, and mitigation actions are visible.

Example Task Decomposition (One PBI)

PBI: “As a customer, I can reset my password via email so I can regain access without support.”

• Confirm email template requirements and localization needs
• Design token generation and expiration rules
• Implement reset request endpoint
• Implement reset confirmation endpoint
• Create UI for request and confirmation (happy path)
• Add validation and error states (expired token, unknown email)
• Add automated tests (unit + integration)
• Add logging/monitoring for reset flow
• Security review checklist items (rate limiting, token storage)
• Update documentation/runbook

New team member tip: If you are unsure how to break down work, ask: “What would we need to code, test, review, and release this safely under our DoD?”

Confirming Shared Understanding and Surfacing Risk

Before ending planning, the team should verify that everyone has the same picture of the Sprint Goal, the selected PBIs, and the plan. This is where many future misunderstandings can be prevented.

Shared Understanding Checks

• Goal alignment: Can each person explain the Sprint Goal in their own words?
• Scope clarity: For each selected PBI, do we know what is in and out for this Sprint?
• Acceptance clarity: Are the key acceptance criteria understood well enough to implement and test?
• DoD impact: Are all quality activities accounted for in the plan?
• Collaboration points: Do we know where we need pairing, reviews, or stakeholder input?

Risk and Dependency Checks

• External dependencies: Are we waiting on another team, vendor, or approval? What is the fallback if it doesn’t arrive?
• Technical unknowns: What assumptions are we making? How will we validate them early?
• Operational risk: Are there production risks, migration steps, or monitoring needs?
• Capacity risk: Are there likely interruptions (support load, on-call)? Is there buffer?

Practical technique: For each major risk, capture a mitigation task in the Sprint Backlog (e.g., “Validate SSO sandbox access on Day 1”).

Realistic Planning Scenario: Building a Sprint Goal and Plan

Context: A team maintains an e-commerce web app. Support reports many tickets about failed checkouts due to address validation errors. The ordered backlog includes address validation improvements, a new promo banner, and a refactor item. Two developers are on vacation for two days each, and one developer is on-call for the first week.

Inputs

• Ordered backlog (top items): (1) Improve address validation for checkout, (2) Add clearer error messages for address form, (3) Promo banner experiment, (4) Refactor checkout module
• Capacity: Reduced by vacations and on-call; team agrees to plan ~20% less than usual
• DoD: Requires automated tests, code review, and monitoring updates for checkout changes
• Constraints: Payment provider maintenance window mid-Sprint; avoid risky checkout deployments that day

Crafting the Sprint Goal

The team discusses outcomes and chooses: “Reduce failed checkout attempts by improving address validation and making address errors actionable for customers.”

This goal is outcome-focused and guides scope decisions: promo banner is not aligned; refactor is only included if it directly enables the validation changes.

Selecting PBIs

• Selected: Improve address validation; Add clearer error messages; Add monitoring for address validation failures
• Not selected: Promo banner experiment (doesn’t support goal); Refactor (too large, not necessary for this Sprint Goal)

Decomposing into a Plan

• Day 1: Confirm current failure patterns from logs; define validation rules and edge cases
• Day 1–2: Implement backend validation changes behind a feature flag
• Day 2–3: Update UI error messaging and inline guidance
• Day 3: Add automated tests for key address scenarios
• Day 4: Add dashboards/alerts for validation failures and checkout drop-offs
• Day 4–5: Gradual rollout plan around the payment provider maintenance window

Shared Understanding and Risk

• Risk: Validation rules might reject legitimate international addresses. Mitigation: Start with top 3 countries by volume; add logging for rejected patterns; keep feature flag for rollback.
• Risk: Reduced capacity due to on-call. Mitigation: Keep the plan focused on the two core PBIs; treat monitoring as essential to DoD for checkout changes.

Checklist: Leave Sprint Planning with Clarity

Sprint Goal

• I can state the Sprint Goal in one sentence and explain why it matters.
• I understand what trade-offs the goal implies (what we would drop first if needed).

Selected Work

• I know which PBIs are in the Sprint and which are explicitly not.
• For each selected PBI, I understand the intended behavior and key acceptance criteria.
• Any unclear PBI has a plan to clarify quickly (question list, quick stakeholder check, or reduced scope).

The Plan (How)

• Each selected PBI has tasks small enough to start immediately.
• Sequencing is visible (what must happen first, what can be parallelized).
• Quality work required by DoD is included as tasks (tests, reviews, docs, monitoring, release steps).

Capacity and Constraints

• Vacations, on-call, and other time constraints are accounted for.
• Known external constraints (maintenance windows, approvals, environment limits) are noted in the plan.

Risks and Dependencies

• Top risks are identified, and at least one mitigation action is planned for each.
• Dependencies have owners and next steps (who will contact whom, by when).

Team Alignment

• I know what I’m starting first and who I’m collaborating with.
• I know where to ask questions during the Sprint if assumptions change.