The Sprint Backlog

The Sprint Backlog is composed of:

1. The Sprint Goal (why)
2. Product Backlog items selected for the Sprint (what)
3. A plan for delivering the Increment (how)

It is a highly visible, real-time picture of the work Developers plan to accomplish during the Sprint.

Key characteristics:

• Owned by Developers: Only they can change it during the Sprint
• Updated daily: As work is completed and new work is discovered
• Living plan: Adapts as the team learns, while protecting the Sprint Goal

The Sprint Backlog is not a contract—it's a plan that evolves.

What can change:

• The tasks and approach (how) adapt as the team learns
• Items can be re-negotiated with the PO if scope exceeds capacity
• New work can be added if capacity allows

What doesn't change:

• The Sprint Goal stays fixed (unless the Sprint is cancelled)
• Quality (Definition of Done) is never compromised

The PO's role during the Sprint:

• Answers questions about items
• Clarifies acceptance criteria
• Negotiates scope if needed
• Does NOT add work without the team's agreement

The Sprint Goal is the commitment for the Sprint Backlog. It provides:

Focus: When someone asks "what should I work on?" the answer relates to the Sprint Goal.

Flexibility: Items can be adjusted as long as the Goal is achievable.

Coherence: The Sprint isn't just random items—it's a meaningful objective.

For stakeholders: A clear statement of what value this Sprint delivers.

If the Sprint Goal becomes obsolete, the Sprint may be cancelled. This is the only reason to end a Sprint early.