HKSM

Previous Sprint Velocity is the total size of work actually completed and accepted in the last sprint, measured in the team’s estimation unit (for example, story points or ideal days). It is captured at the end of the sprint and used as an empirical input to plan the next sprint and forecast releases.

Key Points

• Calculated at the end of a sprint from work that meets the Definition of Done and is accepted by the Product Owner.
• Expressed in the same unit used to estimate user stories, such as story points or ideal days.
• Serves as an input to Approve, Estimate, and Commit User Stories and Create Sprint Backlog in SBOK.
• Typically recorded during Demonstrate and Validate Sprint and refined in Retrospect Sprint.
• Used to forecast the next sprint scope and release timelines; best applied as a range, not a single exact number.
• Not a performance target and not comparable across teams due to different estimation scales and contexts.

Purpose

Previous Sprint Velocity provides a real, recent baseline of the team’s delivery capacity. It supports realistic sprint commitments, improves predictability for stakeholders, and informs release planning based on empirical evidence rather than wishful estimates.

By grounding planning in completed and accepted work, it helps the team negotiate scope, manage risk, and maintain a sustainable pace.

Key Terms & Clauses

• Definition of Done: Only work that meets DoD and is accepted counts toward velocity.
• Estimation Unit: Keep units consistent (story points or ideal days) across sprints.
• Spillover: Partially done stories do not contribute; they count in the sprint when completed.
• Velocity Range: Use a rolling average or range (for example, last 3 sprints) for planning.
• Availability: Account for holidays, leave, and team changes when turning velocity into a working forecast.
• SBOK Linkage: Output of Demonstrate and Validate Sprint; input to Approve, Estimate, and Commit User Stories and Create Sprint Backlog; supports Conduct Release Planning.

How to Develop/Evaluate

1. At Sprint Review, list the user stories accepted by the Product Owner that meet the Definition of Done.
2. Sum their estimates in the team’s unit; the total is the sprint velocity.
3. Record the number on the velocity chart and maintain a rolling average or median across recent sprints.
4. Verify consistency: confirm that estimation scales and DoD have not changed; note any major team composition changes.
5. Evaluate stability: look for large fluctuations that may indicate impediments, scope churn, or estimation issues.

How to Use

During Approve, Estimate, and Commit User Stories, use previous sprint velocity as the baseline to decide how many product backlog items to commit. Select items in priority order until the sum of estimates approaches the target capacity derived from velocity.

In Create Sprint Backlog, break selected stories into tasks and verify that team availability aligns with the velocity-informed scope. During Conduct Release Planning, divide remaining backlog size by average velocity to estimate the number of sprints and timeline options.

Use velocity trends to surface risks in Retrospect Sprint and to trigger impediment removal by the Scrum Master. Communicate forecasts as ranges to stakeholders to reflect uncertainty and maintain transparency.

Example Snippet

Recent velocities: Sprint 8 = 24 points, Sprint 9 = 20 points, Sprint 10 = 22 points. Previous sprint velocity is 22 points, and the 3-sprint average is 22 points.

In Sprint Planning, the team plans a scope of about 20-22 points. If two team members are on leave for 1 day each in a 10-day sprint, the team may plan closer to 18-20 points to account for reduced availability.

Risks & Tips

• Do not use velocity as a target or incentive; it can drive point inflation and reduce quality.
• Avoid mixing estimation scales; changing from ideal days to points (or re-scaling points) resets comparability.
• Only count accepted stories; partial credit hides spillover and impairs forecasting.
• Use a range or rolling average to plan; single-sprint numbers can be noisy.
• Track factors that affect velocity, such as team changes, DoD changes, technical debt, and impediments.
• Do not compare velocities across teams; each team’s context and scale differ.

PMP/SCRUM Example Question

During Sprint Planning, the Scrum Team must decide how many high-priority user stories to commit from the product backlog. Which input should primarily guide the team’s scope selection for this sprint?

1. Management’s quarterly target for story points.
2. The development team’s total available hours multiplied by a focus factor.
3. Previous Sprint Velocity and recent velocity trend, adjusted for known availability.
4. The Product Owner’s desired release date without considering past delivery rates.

Correct Answer: C — Previous Sprint Velocity and recent velocity trend, adjusted for known availability.

Explanation: Empirical velocity is the primary input to commit realistic scope in SBOK processes. Available hours and target dates inform planning, but without velocity they lead to less reliable commitments.