Sprint Backlog: The Plan for the Sprint

Level: Intermediate Module: Scrum Artifacts and Commitments 2 min read Lesson 28 of 52

Overview

  • What you’ll learn: What the Sprint Backlog is, its three components, why it is owned by Developers, how it evolves during the Sprint, and the difference between a static plan and a living artifact.
  • Prerequisites: Lesson 27 — User Stories and PBIs.
  • Estimated reading time: 12 minutes

Introduction

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), plus an actionable plan for delivering the Increment (how). It is a plan by and for the Developers.

Three Components

Component Purpose Owner
Sprint Goal Why — the objective Scrum Team (collaboratively)
Selected PBIs What — the scope Developers (they select)
Delivery Plan How — the tasks Developers (their discretion)

A Living Artifact

The Sprint Backlog is not a static document created during Sprint Planning and forgotten. It is updated throughout the Sprint as the Developers learn more about the work needed to achieve the Sprint Goal. New tasks are added, completed tasks are removed, and the plan adapts daily.

If your Sprint Backlog looks the same on day 1 as it does on the last day, you are either not inspecting and adapting, or you planned perfectly (which never happens).

Ownership

The Sprint Backlog belongs to the Developers. The PO does not add items to the Sprint Backlog mid-Sprint. The SM does not rearrange it. Only the Developers modify it. If the PO discovers something urgent, they discuss it with the Developers, and the team decides whether to adjust scope while protecting the Sprint Goal.

Key Takeaways

  • The Sprint Backlog = Sprint Goal + selected PBIs + delivery plan.
  • It is owned by Developers — not the PO, not the SM.
  • It is a living artifact that evolves daily during the Sprint.
  • Changes to scope must be negotiated; the Sprint Goal is protected.
  • A static Sprint Backlog is a sign that the team is not adapting.

What’s Next

In Lesson 29, you will explore the Sprint Goal in more depth — its role as the Sprint Backlog’s commitment and how it creates flexibility within constraint.

繁體中文

概述

  • 學習目標：Sprint 待辦清單是什麼、三個組成部分、為什麼由開發者擁有、如何在 Sprint 中演化。
  • 先決條件：第 27 課。
  • 預計閱讀時間：12 分鐘

三個組成部分

組成部分 目的 擁有者
Sprint 目標 為什麼——目標 Scrum 團隊（協作）
選定的 PBI 做什麼——範圍 開發者（他們選擇）
交付計劃 怎麼做——任務 開發者（他們的裁量）

活的工件

Sprint 待辦清單不是 Sprint 規劃時創建後就被遺忘的靜態文件。它在 Sprint 中隨著開發者了解更多而更新。如果你的 Sprint 待辦清單從第一天到最後一天都一樣，你可能在做瀑布流。

重點摘要

  • Sprint 待辦清單 = Sprint 目標 + 選定的 PBI + 交付計劃。
  • 由開發者擁有。
  • 是每天演化的活工件。
  • 範圍變更必須協商；Sprint 目標受保護。

下一步

在第 29 課中，您將更深入探索 Sprint 目標作為承諾的角色。

日本語

概要

  • 学習内容：スプリントバックログとは何か、3つの構成要素、開発者が所有する理由、スプリント中の進化。
  • 前提条件：レッスン27。
  • 推定読了時間：12分

3つの構成要素

構成要素 目的 所有者
スプリントゴール なぜ——目標 スクラムチーム（協調的に）
選択されたPBI 何を——スコープ 開発者（選択する）
デリバリー計画 どのように——タスク 開発者（裁量で）

生きたアーティファクト

スプリントバックログはプランニングで作成して忘れる静的ドキュメントではない。スプリント中に開発者が作業について学ぶにつれて更新される。初日と最終日で同じなら、検査と適応をしていないか、完璧に計画した（ありえない）かのどちらか。

重要ポイント

  • スプリントバックログ = スプリントゴール + 選択されたPBI + デリバリー計画。
  • 開発者が所有——POでもSMでもない。
  • スプリント中に毎日進化する生きたアーティファクト。
  • スコープ変更は交渉が必要。スプリントゴールは保護される。

次のステップ

レッスン29では、スプリントゴールのコミットメントとしての役割をより深く探ります。

You Missed