Artifacts

Sprint Backlog

How Developers use the Sprint Backlog and Sprint Goal to plan, execute, and adapt the work of a single Sprint.

What is the Sprint Backlog

The Sprint Backlog is the Developers'/team members' plan for a single Sprint.

It includes three elements:

  • The Sprint Goal
  • The Product Backlog Items (PBIs) selected for the Sprint
  • The plan for delivering the Increment

During Sprint Planning, the Developers/team members pull PBIs, preferably written as User Stories or Job Stories, from the top of the Product Backlog and create a forecast for what they believe they can complete.

Unlike the Product Backlog, which is owned by the Product Owner, the Sprint Backlog is owned and managed by the Developers/team members. It should be visible, detailed enough to track progress daily, and updated throughout the Sprint as more is learned.

Why It Matters

The Sprint Backlog is not just a list of work, it is a commitment-backed plan.

It represents the team's best forecast of how they will achieve the Sprint Goal. When it is clear and realistic:

  • The team works with focus
  • Progress is transparent
  • Delivery becomes predictable over time

When it is not:

  • Teams overcommit and miss goals
  • Work becomes reactive
  • Trust in planning erodes

The Sprint Backlog is where execution discipline shows up. It connects intention to delivery.

How It Works in Scrum

The Sprint Backlog is stable in its intent, but adaptable in its execution.

  • The Sprint Goal should not change during the Sprint
  • The Sprint Backlog evolves as the Developers/team members learn more

As work progresses, the Developers/team members update their plan and, when needed, collaborate with the Product Owner to adjust scope, as long as the Sprint Goal remains achievable.

If a higher-priority item emerges mid-Sprint, it should not be inserted arbitrarily. Strong teams use a clear interruption approach to evaluate whether:

  • The work can wait
  • Scope can be adjusted
  • Or the change is significant enough to justify canceling the Sprint

In rare cases, the Product Owner may abort the Sprint entirely. This is disruptive and should only happen when the Sprint Goal is no longer relevant.

Planning and Forecasting

Scrum does not prescribe a specific estimation method, but experienced teams use proven patterns to improve predictability.

Two common practices are:

  • Story points to estimate relative effort and complexity
  • Yesterday's Weather to forecast capacity based on recent performance

Yesterday's Weather uses the amount of work completed in recent Sprints as the best predictor of what the team can complete next. This prevents overcommitment and stabilizes delivery over time.

These are not required by Scrum, but they are widely used because they work.

Commitment: The Sprint Goal

Every Sprint Backlog is anchored to a Sprint Goal: a single objective that gives the Sprint direction and purpose.

The Sprint Goal is created during Sprint Planning and provides coherence across the selected work. It ensures the team is working toward a shared outcome, not just completing a set of tasks.

It also enables flexibility.

If the work turns out differently than expected, the team can adjust the Sprint Backlog in collaboration with the Product Owner — as long as the Sprint Goal remains intact.

The key distinction:

  • The Sprint Goal is the commitment
  • The Sprint Backlog is the plan to meet it

Common Mistakes

  • Treating the Sprint Backlog as fixed scope. The plan should evolve as the team learns. The goal is what remains stable.
  • Estimating in hours instead of relative effort. Time-based estimates introduce variability and reduce forecasting accuracy.
  • Adding work mid-Sprint without a clear approach. Uncontrolled changes disrupt focus and reduce predictability.
  • Treating the Sprint Backlog as a task list. It is a goal-oriented plan, not a checklist.
  • Ignoring historical capacity (Yesterday's Weather). Overcommitting consistently undermines predictability and team trust.

Key Takeaways

  • The Sprint Backlog is the Developers'/team members plan for the Sprint
  • It includes the Sprint Goal, selected PBIs, and the plan to deliver the Increment
  • The Sprint Goal is stable; the Sprint Backlog evolves as work progresses
  • Estimation and forecasting methods like points and Yesterday's Weather improve predictability
  • Scope can flex during the Sprint; the commitment to the goal cannot