HKSM

Estimate Tasks is the process where the Scrum Team sizes each task for the selected user stories to forecast effort and check Sprint feasibility.

Purpose & When to Use

Estimate Tasks converts identified tasks into effort forecasts so the team can validate scope against capacity, sequence work, and expose risk. Use it during Sprint Planning after user stories are committed and tasks are identified, and refine estimates during the Sprint if new tasks emerge or understanding changes.

Mini Flow (How It’s Done)

• Prepare inputs: committed user stories, task list, Definition of Done, team calendar and capacity, historical data.
• Agree units and policy: ideal hours (or ideal person-hours), max task size (e.g., 4–12 hours), and when to split tasks.
• Clarify acceptance criteria and dependencies so estimators understand scope and quality expectations.
• Select techniques per task: expert judgment, analogous comparison, three-point estimation (optimistic, most likely, pessimistic), or parametric rates; use spikes (time-boxed investigation) for high uncertainty.
• Estimate collaboratively: the people who will do the work drive the numbers; Scrum Master facilitates; Product Owner clarifies scope but does not set estimates.
• Record assumptions and constraints for each task so future adjustments are traceable.
• Roll up: sum task effort per story and across the Sprint; check against team capacity (consider availability, holidays, pairing, WIP limits).
• Adjust plan: split oversized tasks, remove or defer lower-value stories with the Product Owner, or schedule spikes to reduce risk; update the Sprint Backlog with task estimates.
• Make it transparent: highlight external dependencies, handoffs, and risks on the board; revisit estimates as new information appears.

Quality & Acceptance Checklist

• Estimates were created by the people who will perform the work; no one outside the team overrode them.
• Tasks are small enough to finish within one day (typical target 4–12 ideal hours) or are split further.
• All work to meet Definition of Done is included: development, testing, integration, documentation, reviews, and fixes.
• Assumptions, constraints, and external dependencies are documented for tasks with uncertainty.
• Three-point or spike used for high-risk or novel work instead of padding single-point estimates.
• Total estimated effort fits within realistic team capacity for the Sprint.
• Non-working time (meetings, holidays, support) is accounted for in capacity, not baked into task estimates as hidden buffer.
• Estimates reflect effort, not elapsed calendar time or wait time outside the team’s control.

Common Mistakes & Exam Traps

• Using story points for tasks (tasks are usually estimated in hours or similar effort units).
• Letting the Product Owner or management push estimates down; estimates must come from the team.
• Confusing estimate with commitment; estimates forecast effort, while Sprint commitment is the subset of work the team believes it can finish.
• Padding estimates instead of using uncertainty management (three-point estimates, spikes, or splitting work).
• Ignoring non-development tasks (testing, integration, documentation), leading to underestimation.
• Failing to check capacity, resulting in overstuffed Sprints.
• Re-estimating user stories because task estimates changed; adjust the Sprint plan, not historical story points.
• Assuming individual utilization at 100%; effective capacity is lower due to collaboration, meetings, and context switching.

PMP/SCRUM Example Question

During Sprint Planning, the team’s summed task estimates for the selected stories exceed their available capacity. What should the Scrum Team do next?

1. Keep all stories and plan overtime to meet the Sprint Goal.
2. Ask the Product Owner to re-prioritize and remove the lowest-value stories from the Sprint.
3. Increase individual task estimates to include larger buffers.
4. Have the Scrum Master decide which tasks to drop to protect the team.

Correct answer: B. Explanation: When capacity is exceeded, adjust scope collaboratively by re-prioritizing with the Product Owner; do not rely on overtime, padding, or top-down decisions.