HKSM

A timeboxed, team-owned plan of work for the sprint that lists the selected product backlog items and the detailed tasks and estimates to achieve the Sprint Goal. It is created in Sprint Planning and updated daily as a living forecast of progress and remaining effort.

Key Points

• Subset of the product backlog selected for the sprint, broken down into tasks with estimates.
• Owned and maintained by the Scrum Team; it evolves throughout the sprint.
• Created during Sprint Planning and updated in the Daily Standup.
• Provides transparency of work, remaining effort, and impediments.
• Aligned with the Sprint Goal and the team’s Definition of Done.
• Output of Create Sprint Backlog; input to Create Deliverables and Conduct Daily Standup in SBOK.

Purpose

The Sprint Backlog provides a realistic, shared plan for the sprint that the team can inspect and adapt daily. It enables focus on the Sprint Goal, supports self-organization, and improves transparency for stakeholders.

By breaking stories into tasks and estimating effort, the team can balance capacity, manage risk, and forecast completion using visible indicators like a sprint burndown chart.

Key Terms & Clauses

• Sprint Goal: The objective the team aims to meet; it guides selection and adjustment of work.
• Tasks and Estimates: Detailed work items (often in hours) derived from user stories; updated daily with remaining effort.
• Ownership: The Scrum Team manages the Sprint Backlog; the Product Owner clarifies scope and priorities.
• Changes in Sprint: Items may be added, split, or swapped only by mutual agreement if the Sprint Goal is protected.
• Transparency: Kept visible via a task board or tool, often linked to a sprint burndown chart.
• SBOK Linkage: Produced in Create Sprint Backlog after Estimate Tasks; used by Create Deliverables, Conduct Daily Standup, and Demonstrate and Validate Sprint.

How to Develop/Evaluate

Develop

1. Select top prioritized product backlog items that support the Sprint Goal during Sprint Planning.
2. Break each selected story into concrete tasks; estimate task effort and identify dependencies.
3. Check team capacity, adjust scope, and confirm acceptance criteria coverage via tasks.
4. Define update rules (when and how remaining hours are revised) and set up the board or tool.

Evaluate

• Scope fits the team’s capacity with buffer for risk and uncertainty.
• Tasks are small, testable, and traceable to acceptance criteria and Definition of Done.
• Dependencies and impediments are visible with clear owners.
• Burndown trend is feasible based on initial remaining effort.

How to Use

• Drive daily work: pull tasks, update remaining effort, and move items across To Do, In Progress, and Done.
• Support the Daily Standup: discuss progress, next steps, and impediments using the current Sprint Backlog.
• Adapt the plan: split tasks, reorder work, or negotiate swaps with the Product Owner if the Sprint Goal remains achievable.
• Track progress: feed data into the sprint burndown and report on done stories at the Sprint Review.

Example Snippet

Sample entries for a two-week sprint:

• Story US-24 Reset password — Tasks: Design flow (4h), Build API endpoint (10h), UI form (8h), Unit tests (6h), QA tests (6h).
• Story US-31 Update profile — Tasks: Database change (6h), Service layer (6h), UI update (6h), Integration tests (5h).
• Chore CH-07 CI pipeline fix — Tasks: Update build script (3h), Add smoke test (2h).

Risks & Tips

• Risk of overcommitment — calibrate with historical velocity and team capacity.
• Vague tasks slow progress — ensure tasks are small and outcome-focused.
• Hidden dependencies cause delays — surface them early and sequence tasks.
• Stale backlog undermines transparency — update remaining effort daily.
• Micromanagement by hours — treat estimates as a forecast, not a contract.
• Excess WIP reduces flow — encourage swarming to finish items before starting new ones.

PMP/SCRUM Example Question

Mid-sprint, a stakeholder asks the Product Owner to add a new high-priority user story. What should the Scrum Master advise regarding the Sprint Backlog?

1. Add the story immediately and keep the original scope to preserve stakeholder trust.
2. Reject any change; the Sprint Backlog cannot be modified after Sprint Planning under any circumstances.
3. Facilitate a discussion with the team and Product Owner to swap or adjust scope only if the Sprint Goal remains achievable.
4. Allow the stakeholder to edit the Sprint Backlog directly in the tool to save time.

Correct Answer: C — Facilitate a discussion with the team and Product Owner to swap or adjust scope only if the Sprint Goal remains achievable.

Explanation: The Sprint Backlog is team-owned and can be adapted by mutual agreement if it does not endanger the Sprint Goal. Unilateral changes or adding scope without adjustment are not appropriate.