HKSM

A Task List is a living, detailed list of all tasks required to complete the committed user stories in a sprint. It is created during Sprint Planning when the team identifies and estimates tasks, then updated daily with ownership, status, and remaining effort. It connects to the Scrumboard and burndown chart and serves as an input to Daily Standup and impediment management.

Key Points

• Acts as both an input and an output across Scrum processes such as Identify Tasks, Estimate Tasks, Create Sprint Backlog, and Conduct Daily Standup.
• Owned and maintained by the Developers; neither the Product Owner nor Scrum Master assigns tasks.
• Includes task-level data such as description, story link, estimate, owner, status, dependencies, and remaining effort.
• Continuously updated to reflect progress, new discoveries, splits, and re-estimates.
• Feeds the Scrumboard for visual tracking and the Sprint Burndown for remaining effort trends.
• Supports transparency, self-organization, and timely impediment escalation.

Purpose

The Task List breaks user stories into actionable work so the team can plan daily, self-organize, and track progress toward the Sprint Goal. It offers just enough structure to manage scope at the task level without micro-managing individuals.

It also enables quick reporting of remaining effort, highlights blockers and dependencies, and provides a single reference for what is being worked on today and what comes next.

Key Terms & Clauses

• Task ID - A simple identifier to reference the task.
• Story Link - The user story or epic the task supports.
• Description - Concise statement of the work to be done.
• Estimate - Effort forecast, commonly in hours or ideal hours.
• Remaining Effort - Updated daily to reflect how much work is left.
• Owner - Current person doing the work; ownership can change as needed.
• Status - Typical states: To Do, In Progress, Done; a Blocked flag may be used.
• Dependencies - Notes on sequencing or external needs.
• Priority/Order - Execution order that aligns with the Sprint Goal and flow.
• Done Check - How completion will be verified, aligned with the Definition of Done.

How to Develop/Evaluate

1. Decompose each committed user story into small, testable tasks during Sprint Planning (Identify Tasks).
2. Estimate tasks collaboratively (Estimate Tasks), aiming for right-sized chunks, often 2-12 hours each.
3. Link each task to its story, ensure acceptance criteria are traceable, and capture dependencies.
4. Validate capacity by summing task estimates against team availability and adjust as needed.
5. Review quality: every task advances the Sprint Goal, includes necessary testing and integration work, and meets the team’s Definition of Done when completed.
6. Keep it emergent: add, split, or remove tasks as more is learned, while maintaining story scope and alignment.

How to Use

During Daily Standup, update status, owners, and remaining effort, and move tasks on the Scrumboard. Use it to surface blockers early and create or update entries in the Impediment Log.

The Scrum Master uses it to facilitate flow and remove impediments; the Product Owner observes for transparency but does not direct task assignments. Update the Sprint Burndown from remaining effort to track trends.

Example Snippet

• US-15 - Implement password reset: T-01 - Design flow (4h, Owner: Kim, Status: Done).
• US-15 - Implement password reset: T-02 - Build API endpoint (8h, Owner: Raj, In Progress, Remaining: 5h, Dep: DB schema).
• US-15 - Implement password reset: T-03 - UI form and validation (6h, Owner: Alex, To Do, Dep: T-02).
• US-15 - Implement password reset: T-04 - Unit and integration tests (6h, Owner: Sam, To Do).
• US-15 - Implement password reset: T-05 - Update help docs and DoD checks (2h, Owner: Pat, To Do).

Risks & Tips

• Risk - Tasks too large: Split into smaller, testable pieces to expose progress and issues sooner.
• Risk - Stale data: Update remaining effort daily to keep burndown and forecasts reliable.
• Risk - Hidden dependencies: Capture and review dependencies to prevent late surprises.
• Tip - Include testing, deployment, and documentation tasks to reflect end-to-end work.
• Tip - Keep ownership fluid; let the team self-organize and swam on bottlenecks.
• Tip - Use Blocked flags and Impediment Log entries to make issues visible and actionable.

PMP/SCRUM Example Question

During Sprint 2, the team discovers an additional data-migration step is needed to complete a committed user story. What should the Scrum Master coach the team to do regarding the Task List?

1. Add it to the Product Backlog for the Product Owner to prioritize in a future sprint.
2. Freeze the Task List and request a formal change to the Sprint scope.
3. Add the new task to the Task List, estimate it collaboratively, and update the Scrumboard and burndown.
4. Assign the task to the most available developer and report the change to management.

Correct Answer: C — Add the new task to the Task List, estimate it collaboratively, and update the Scrumboard and burndown.

Explanation: The team can add and refine tasks during the sprint to achieve the Sprint Goal. Tasks are owned by the team, kept current, and used to update visual tracking and remaining effort.