HKSM

Pre-existing estimates for tasks are previously recorded effort or duration figures for similar Sprint tasks, captured from earlier Sprints or organizational assets. They are used as reference inputs when estimating current tasks and planning team capacity, and serve as outputs from past estimation activities.

Key Points

• Serves as an Input to Estimate Tasks and Sprint Planning activities in SBOK.
• Originates as an Output from earlier Sprints, historical repositories, or vendor benchmarks.
• Used to anchor, calibrate, and cross-check new task estimates by the Development Team.
• Improves consistency across Sprints when the work is genuinely comparable.
• Must be adjusted for context differences such as technology, team skills, and Definition of Done.
• Supports capacity planning and Sprint Burndown forecasting, but does not replace team judgment.

Purpose

Pre-existing estimates provide a quick starting point for estimating Sprint tasks, reducing guesswork and rework. They help the team forecast effort, align workload with capacity, and maintain estimation consistency across similar work.

Key Terms & Clauses

• Reference task: A previously completed task used as a comparison anchor for a new task.
• Ideal hours: Team-estimated effort excluding interruptions, commonly used for task-level estimates.
• Similarity criteria: Factors used to judge comparability, such as complexity, platform, dependencies, and team skill.
• Calibration: Adjusting a reference estimate to reflect current context and Definition of Done.
• Estimate-to-actual variance: The observed difference used to refine future estimates.
• Organizational process asset: The repository where estimates and actuals may be stored for reuse.

How to Develop/Evaluate

• Collect historical task estimates and actuals from prior Sprints, Sprint Backlogs, and retrospectives.
• Tag each item with context: technology stack, complexity, team composition, and Definition of Done version.
• Normalize units (e.g., convert elapsed time to ideal hours) and remove outliers that reflect unusual conditions.
• Cluster similar tasks and compute typical ranges (e.g., 50th and 90th percentile) rather than single-point values.
• Assess reliability by checking estimate-to-actual variance and recency; prefer recent, low-variance data.
• Document assumptions and known dependencies to avoid blind reuse.

How to Use

• During Sprint Planning and Estimate Tasks, present comparable reference tasks to the team as a starting point.
• Facilitate team discussion to adjust estimates for current complexity, skills, and Definition of Done.
• Feed the calibrated estimates into the Sprint Backlog for capacity balancing and initial Sprint Burndown setup.
• Revisit estimates during Daily Standup if new information emerges, updating remaining hours transparently.
• Capture actuals and variances at Sprint close and store them to enhance the pre-existing estimates library.

Example Snippet

A team reviews three past tasks labeled similar in scope and tech stack:

• Configure rule change: estimated 6 ideal hours, actual 7 hours.
• Add simple validation: estimated 5 hours, actual 5 hours.
• Update report filter: estimated 6 hours, actual 6.5 hours.

For a new, comparable task, the team sets a range of 5–7 ideal hours, noting one extra dependency that may push the high end.

Risks & Tips

• Anchoring bias: Teams may accept old numbers without questioning fit; always confirm similarity first.
• Context drift: Changes in tools, team skills, or Definition of Done can invalidate past estimates.
• False precision: Single-point reuse hides uncertainty; prefer ranges when appropriate.
• Data quality: Outdated or high-variance entries reduce usefulness; curate the repository regularly.
• Misuse as commitment: Estimates are forecasts, not fixed contracts; maintain transparency on uncertainty.
• Tip: Store both estimate and actual with notes, tags, and links to the original PBI for traceability.

PMP/SCRUM Example Question

During Sprint Planning, a developer proposes copying task hours from similar work done two Sprints ago to speed up estimation. What should the Scrum Master encourage the team to do?

1. Reuse the old hours as-is to save time and lock the Sprint scope.
2. Ask the Product Owner to provide task-hour estimates since they know priorities.
3. Convert the user story's story points directly into task hours using a fixed ratio.
4. Use the past hours as a reference, then adjust based on current complexity, skills, and Definition of Done.

Correct Answer: D — Use the past hours as a reference, then adjust based on current complexity, skills, and Definition of Done.

Explanation: Pre-existing estimates are helpful inputs but must be calibrated by the Development Team for the current context. Copying numbers, delegating to the Product Owner, or converting story points directly can lead to inaccurate forecasts.