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 (Development, QA, DevOps) 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, each delivery role (Development, QA, DevOps) brings the estimates it prepared after grooming, the team reviews and confirms them, 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, DevOps, 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. Each delivery role (Development, QA, DevOps) presents the estimates it prepared after grooming; the team reviews and confirms them.
  4. Based on team capacity (after subtracting spillover), the team finalizes the sprint backlog.

Estimation rules

  • Estimates are prepared by each delivery role (Development, QA, DevOps) after grooming and confirmed together in planning, not produced from scratch in the meeting.
  • Story-level estimates are given in hours for now. Story points (relative size and complexity) may be adopted later once the team is comfortable with relative estimation; until then all estimates are in 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 confirms prepared estimates in hours from Dev, QA, DevOps]
    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). Because QA takes part in planning, it leaves knowing the committed scope and can begin its impact analysis and test case design in parallel with development (see Test Case Design & ITCR).

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 carries an hours estimate, sub-tasks are estimated in hours, and the sprint's JIRA Release v1.4.0 is created as the container for all of it.