9.4 Identify Tasks
| 9.4 Identify Tasks | ||
|---|---|---|
| Inputs | Tools | Outputs |
Bold ITTOs are mandatory.
Identify Tasks is the Scrum process where the team breaks selected user stories into small, testable, and estimable tasks to form the Sprint Task List used to manage daily work.
Purpose & When to Use
The purpose of Identify Tasks is to translate each selected user story into concrete pieces of work that the team can execute, track, and complete within the Sprint.
Use it during Sprint Planning right after the Sprint Goal and stories are chosen, and continue to use it throughout the Sprint when new work is discovered or existing tasks need to be refined.
- Creates the Sprint Task List and updates the Scrum Board.
- Improves transparency for forecasting and daily coordination.
- Provides the baseline for the Sprint Burndown and capacity checks.
Mini Flow (How It’s Done)
- Confirm inputs: Sprint Goal, selected user stories with acceptance criteria, Definition of Done, team capacity, and any known risks or constraints.
- For each user story, brainstorm vertical-slice tasks that jointly deliver the story’s acceptance criteria; include build, test, integration, review, documentation, and release tasks as needed.
- Write concise task titles and short descriptions; link every task to its parent user story and note dependencies.
- Estimate task effort (typically in hours or ideal hours) and check that the total planned effort fits the team’s capacity; adjust scope or split stories if needed.
- Optionally note likely owners, but allow self-assignment during the Daily Scrum to keep flow flexible.
- Create timeboxed spike tasks where uncertainty blocks decomposition or estimation, and capture assumptions and expected outcomes.
- Publish tasks to the Scrum Board, initialize the Sprint Task List, and set the starting point for the Sprint Burndown.
Quality & Acceptance Checklist
- Every selected user story has enough tasks to satisfy its acceptance criteria and the Definition of Done.
- Most tasks are small (about 4–12 hours each); larger tasks are split where practical.
- Tasks include testing, code review, integration, documentation, and any non-functional or compliance work.
- Each task is clearly named, linked to a user story, and has visible dependencies and constraints.
- Task estimates are team-generated and align with capacity; buffer for meetings, support, and variability is considered.
- Spikes are identified, timeboxed, and have clear learning objectives.
- Risks, assumptions, and external handoffs are captured as tasks or impediments.
- No orphan tasks that do not support the Sprint Goal or a selected story.
- The Scrum Board reflects the initial workflow states to enable flow from Day 1 of the Sprint.
- Burndown baseline recorded and visible to the team.
Common Mistakes & Exam Traps
- Confusing tasks with user stories; stories deliver customer value, tasks are internal steps.
- Estimating tasks in story points instead of hours/ideal hours, making capacity checks unreliable.
- Creating tasks that are too large, causing poor visibility and late discovery of issues.
- Ignoring testing, integration, and documentation tasks; the story can’t be Done without them.
- Freezing the task list; in Scrum, tasks can emerge and change as learning occurs.
- Having the Scrum Master or a manager assign tasks; self-organization and self-assignment are key.
- Skipping spikes when uncertainty is high, leading to inaccurate estimates and rework.
- Planning to 100% of capacity without accounting for meetings, support, and variability.
PMP/SCRUM Example Question
During Identify Tasks, the team struggles to decompose a complex user story because they lack technical clarity. What is the best next step?
- Ask the Scrum Master to assign tasks based on prior projects.
- Create a timeboxed spike task to explore the unknowns and collaborate with the Product Owner to clarify acceptance criteria.
- Skip the story and proceed with the Sprint without any related work.
- Estimate the story’s tasks in story points and finalize the Sprint plan.
Correct Answer: B. A timeboxed spike plus clarification with the Product Owner reduces uncertainty, enables meaningful task decomposition, and supports realistic estimation.
HKSM