Skip to content

2. Planning & Estimation
What Committing a realistic sprint backlog based on priorities and team capacity.
Owner Project Manager facilitates, Product Owner sets priority, the whole team estimates.
Triggers The second-to-last day of the current sprint.

Summary

Sprint planning is where the groomed backlog becomes a committed plan. The Product Owner presents the highest-priority ready stories, the team estimates them in story points, and the team commits only to what its capacity allows after accounting for spillover from the current sprint. The output is a committed sprint backlog that is both aligned with business priorities and honest about what can actually be delivered.

Full detail

Cadence and participants

  • Frequency: second-to-last day of the current sprint.
  • Duration: about one hour.
  • Participants: Project Manager, Developers, QA, Product Owner. Business Owner or CEO optional.

Agenda

  1. Review ongoing stories and identify any spillover work that will carry into the next sprint.
  2. The Product Owner presents priority stories for the upcoming sprint.
  3. The team estimates stories in story points.
  4. Based on team capacity (after subtracting spillover), the team finalizes the sprint backlog.

Estimation rules

  • Story-level estimates are given in story points (relative size and complexity, not hours).
  • Task-level estimates (the sub-tasks under a story) are given as original estimates in hours.
  • A story that cannot be estimated is not ready: send it back to grooming rather than guessing.

Capacity and spillover

Capacity is not the raw number of working days. Subtract known leave, meetings, support duty, and any spillover stories already in flight. Committing to full theoretical capacity is the most common cause of chronic spillover.

flowchart TD
    A[Ready backlog from grooming] --> B[Review spillover from current sprint]
    B --> C[PO presents priority stories]
    C --> D[Team estimates in story points]
    D --> E[Sub-tasks estimated in hours]
    E --> F{Fits remaining capacity?}
    F -->|no| G[Defer lowest-priority stories]
    G --> F
    F -->|yes| H[Commit sprint backlog]
    H --> I[Create JIRA Release for the sprint]

Outcome

A committed sprint backlog aligned with team capacity and business priorities, with every committed story mapped to the sprint's JIRA Release and broken into role-specific sub-tasks (Backend, Frontend, DevOps, QA).

Example

The team has ten working days and six engineers, but two stories spilled over from the prior sprint and one engineer is on leave for three days. Rather than pulling in eight new stories, the team commits five, leaving headroom. Each committed story is pointed, sub-tasks are estimated in hours, and the sprint's JIRA Release v1.4.0 is created as the container for all of it.