HKSM

A living, continuously maintained list of sprint work that shows the latest tasks, status, owners, and remaining effort needed to meet the Sprint Goal. It is revised by the Development Team throughout the sprint, especially after the Daily Standup, and is used to steer day-to-day execution and transparency.

Key Points

• Living artifact owned and maintained by the Development Team.
• Reflects current tasks, status, owners, dependencies, impediments, and remaining effort.
• Updated multiple times per day, with a formal refresh after the Daily Standup.
• Output of Conduct Daily Standup and Create Deliverables; input to Update Sprint Burndown Chart, Demonstrate and Validate Sprint, and Retrospect Sprint.
• Task-level changes are expected; changes that alter sprint scope require collaboration with the Product Owner.
• Provides transparency via the Scrumboard and keeps the team aligned to the Sprint Goal.

Purpose

The artifact makes current work and progress visible so the team can inspect and adapt daily. It supports forecasting through remaining effort, drives conversations about risks and impediments, and anchors the team to the Sprint Goal.

It also feeds reporting tools like the Sprint Burndown Chart and prepares evidence for the Sprint Review and Retrospective.

Key Terms & Clauses

• User story - a product backlog item selected for the sprint.
• Task - a unit of work that helps complete a user story.
• Remaining effort - updated estimate of work left, often in hours or ideal hours.
• Task owner - the person currently responsible for a task.
• Impediment - anything blocking progress, with an owner for removal.
• Dependency - a needed input or predecessor that affects sequencing.
• Definition of Done - quality bar that tasks must satisfy to complete a story.
• Scope guardrail - story-level changes require Product Owner agreement; task updates are team-managed.

How to Develop/Evaluate

Build and refine the artifact collaboratively and keep it current during the sprint.

• Initialize during Sprint Planning with selected user stories and initial tasks and estimates.
• After each Daily Standup, update task status, owners, and remaining effort.
• Add, split, or remove tasks as the team learns what is needed to meet the Definition of Done.
• Record impediments and dependencies with clear owners and due dates.
• Reorder tasks to manage risk and flow, and sync with the Scrumboard and burndown.

• Evaluation checklist: every story has tasks tied to acceptance criteria; each task has an owner, status, and remaining effort; impediments are visible; changes are traceable; alignment with the Sprint Goal is intact.

How to Use

• Plan daily work and coordinate handoffs and dependencies across team members.
• Update the Sprint Burndown Chart based on remaining effort.
• Highlight and escalate impediments to the Scrum Master for removal.
• Prepare for Demonstrate and Validate Sprint by confirming completed stories against acceptance criteria.
• Bring into Retrospect Sprint to discuss flow issues, blockers, and estimation accuracy.

Example Snippet

• Sprint Goal: Enable users to reset passwords securely.
• Story PBI-23: As a user, I can request a password reset link. Acceptance: email sent, link expires, audit logged.
• Tasks:
  • Implement reset endpoint - Owner: Ana - Status: In progress - Remaining: 6h.
  • Create email template - Owner: Lee - Status: Done - Remaining: 0h.
  • Write integration tests - Owner: Ravi - Status: Blocked - Remaining: 4h - Impediment: waiting for test data.
• Burndown impact: remaining work decreased from 64h to 58h after updates.

Risks & Tips

• Risk: Stale updates lead to poor forecasting. Tip: enforce daily updates and visible ownership.
• Risk: Hidden impediments slow progress. Tip: log every blocker with an owner and review at standup.
• Risk: Excessive WIP delays flow. Tip: limit parallel tasks and finish before starting new work.
• Risk: Mid-sprint scope churn. Tip: collaborate with the Product Owner before altering selected stories.
• Risk: Overly large tasks mask progress. Tip: split tasks to 1-2 day size for better tracking.
• Risk: Misaligned quality. Tip: tie tasks to Definition of Done and acceptance criteria.

PMP/SCRUM Example Question

After the Daily Standup, the team realizes more testing work is needed to meet the Definition of Done for a selected user story. What should the Scrum Master encourage the team to do?

1. Add the new testing tasks to the Updated Sprint Backlog and adjust remaining effort.
2. Submit a change request to a change control board before adding any tasks.
3. Cancel the sprint and replan with the Product Owner.
4. Lock the sprint backlog to avoid disrupting the original plan.

Correct Answer: A — Add the new testing tasks to the Updated Sprint Backlog and adjust remaining effort.

Explanation: The team owns and updates the sprint backlog as learning emerges, adding or changing tasks to meet the Definition of Done. A change control board is not used in Scrum, and canceling or locking the sprint is unnecessary for task-level adjustments.