HKSM

Previously recorded size or effort values for backlog items, often in story points, gathered from earlier refinement, prior releases, spikes, or historical data. They serve as a starting reference and are validated or recalibrated by the Scrum Team during Estimate User Stories and Sprint Planning.

Key Points

• Represents prior size or effort values attached to user stories before the current estimation session.
• Acts as an input to Estimate User Stories, Commit User Stories, and Sprint Planning.
• Common sources include earlier backlog refinement, similar past stories, spikes, and organizational benchmarks.
• Subject to validation and change by the Development Team with Product Owner input.
• Helps accelerate planning but must not become a commitment without team confirmation.
• Updated estimates flow forward as outputs that inform velocity planning and release forecasting.

Purpose

Pre-existing estimates help the team start with a baseline instead of estimating from scratch. They reduce cycle time in refinement and planning and support early release sizing.

As an input, they enable quick comparison and triage of large backlogs. As an output, once validated or revised, they connect to forecasts, capacity decisions, and product backlog ordering.

Key Terms & Clauses

• Story points: Relative sizing unit used for user stories.
• Reference story: A well-understood story used to calibrate the scale.
• Seed estimate: A provisional value carried forward until the team confirms or changes it.
• Source tag: A note showing where the estimate came from (spike, prior sprint, vendor, legacy tool).
• Validity window: A time frame after which stale estimates should be reviewed.
• Assumption note: Constraints or dependencies that influenced the prior estimate.

How to Develop/Evaluate

1. Gather sources: Pull earlier values from refinement notes, past releases, spikes, or historical repositories.
2. Normalize units: Ensure all values are on the same relative scale and tied to a current reference story.
3. Check context: Compare acceptance criteria, dependencies, and technology to confirm similarity to the original basis.
4. Spot-change triggers: Re-estimate if the team composition, architecture, or scope has changed materially.
5. Record metadata: Add source, date, and assumptions to make later review transparent.
6. Flag uncertainty: Mark high-variability items for deeper discussion or a quick spike.

How to Use

During Estimate User Stories, the team reviews pre-existing values to anchor discussion and then confirms, increases, or decreases the size via collaborative techniques like Planning Poker. The Product Owner provides context and clarifies acceptance criteria to support adjustments.

In Commit User Stories and Sprint Planning, validated estimates guide capacity fit and selection. Updated values feed into maintain-and-prioritize backlog activities and support release planning and velocity-based forecasting.

Example Snippet

• US-104: Pre-existing 5 points (source: Refinement on 2025-05-03). Team confirms at 5 after clarifications.
• US-219: Pre-existing 8 points (source: prior release). Architecture changed; team revises to 13.
• US-301: Pre-existing 3 points (source: vendor note). Lacks acceptance criteria; marked provisional pending a spike.

Risks & Tips

• Anchoring bias: Treat earlier values as a starting hypothesis, not a decision.
• Stale data: Revisit estimates after major scope, tech, or team changes.
• Mixed units: Do not mix ideal hours with story points; pick one relative scale for sizing.
• Assumption drift: Keep source and assumptions visible to avoid misplaced confidence.
• Team ownership: The current Development Team must own the estimate, even if a prior team created it.
• Use spikes: Time-box short investigations when uncertainty blocks confirmation.

PMP/SCRUM Example Question

A Scrum Team inherits a product backlog where many user stories already have story point values from a previous team. What should the Scrum Master encourage the team to do during Estimate User Stories?

1. Accept the existing values to avoid rework and start delivery immediately.
2. Convert the values into ideal hours to improve accuracy.
3. Average the existing values with new guesses from the Product Owner.
4. Use the existing values as a starting point and re-estimate collaboratively as needed.

Correct Answer: D — Use the existing values as a starting point and re-estimate collaboratively as needed.

Explanation: Pre-existing estimates are inputs, not commitments. The current Scrum Team validates and adjusts them to reflect current scope, technology, and team capability.