HKSM

A continuous Scrum activity where the Developers revise task details, remaining work, and discovered tasks so the Sprint Backlog stays accurate and aligned to the Sprint Goal.

Purpose & When to Use

The goal of updating the Sprint Backlog is to keep the team's plan current, transparent, and achievable so the Sprint Goal remains realistic. It reflects real progress, new insights, and capacity changes as the Sprint unfolds.

• Maintain a single source of truth for the Sprint plan.
• Expose risks, blockers, and capacity shifts early.
• Capture newly discovered work needed to meet acceptance criteria and Definition of Done.
• Keep the Sprint Burndown and task board accurate for forecasting.

Use this process throughout the Sprint—before and after the Daily Standup, whenever work is completed, estimates change, tasks are split/added/removed, or impediments appear.

Mini Flow (How It’s Done)

• Inputs: Sprint Goal, selected Product Backlog Items (PBIs) with acceptance criteria, Definition of Done, current impediments, team capacity.
• 1) Review current state: pull latest task board and remaining work figures.
• 2) Update tasks: mark done/in-progress, adjust remaining hours, and note owners or pairs.
• 3) Add/split/remove tasks: capture newly discovered work required to complete selected PBIs; remove obsolete tasks.
• 4) Flag blockers: tag blocked tasks and log issues in the Impediment Log; identify help needed.
• 5) Re-estimate and check capacity: reconcile remaining work versus available time; rebalance work within the team.
• 6) Validate Sprint Goal alignment: if at risk, discuss trade-offs; negotiate any PBI changes with the Product Owner.
• 7) Refresh radiators: update Sprint Burndown and task board for full transparency.
• Roles: Developers own and update the Sprint Backlog; Scrum Master coaches on process and removes impediments; Product Owner is consulted on scope or PBI swaps.

Quality & Acceptance Checklist

• Every selected PBI has tasks that cover build, test, integration, and any compliance/docs needed to meet Definition of Done.
• Tasks are small and testable (ideally 1 day or less); oversized tasks are split.
• Each task shows remaining effort (not just hours spent or percent complete).
• Blocked items are clearly flagged with the blocker cause recorded.
• Dependencies and external handoffs are visible and owned.
• Changes that affect scope or Sprint Goal are discussed with the Product Owner before committing.
• Burndown and task board reflect current reality by end of day.
• Non-functional and testing work is included, not assumed.
• Ownership is clear (individual or pair) and WIP limits are respected if used.

Common Mistakes & Exam Traps

• Treating the Sprint Backlog as static; it should evolve daily.
• Tracking effort spent instead of remaining effort—forecasts require remaining work.
• Silently adding new PBIs mid-sprint without Product Owner agreement; tasks can change, PBI scope needs PO involvement.
• Skipping test/QA/refactoring tasks, causing “done” to miss the Definition of Done.
• Keeping large, vague tasks that mask risk; split them to expose reality.
• Using percentage complete to look good on burndown; it hides real progress.
• Confusing Product Backlog (product-wide, ordered by PO) with Sprint Backlog (developers’ plan for the Sprint).
• Treating the Daily Standup as status reporting to the Scrum Master; it is for the team to plan the next 24 hours and update the Sprint Backlog.

PMP/SCRUM Example Question

During a Sprint, the team discovers additional testing tasks required to meet the Definition of Done for a selected PBI. What should they do next?

1. Add the tasks to the Product Backlog and defer them to a future Sprint.
2. Add the tasks to the Sprint Backlog, re-estimate remaining work, and assess impact on the Sprint Goal.
3. Escalate to the Scrum Master to get approval before changing the Sprint Backlog.
4. Ask stakeholders for permission to extend the Sprint by one day to complete the tasks.

Correct answer: B. Developers own the Sprint Backlog and should add necessary tasks, update remaining effort, and check capacity; if the Sprint Goal is threatened, they collaborate with the Product Owner on options.