HKSM

The rate at which a team completes work each iteration, usually measured in story points or completed backlog items. It helps track schedule performance and forecast how many iterations are needed to deliver the planned scope.

Key Points

• Calculated per iteration by summing the size of work items completed to the team’s Definition of Done.
• Best used as a rolling average to smooth variability and support near-term forecasting.
• Context-specific and not comparable across teams due to different estimation scales and working methods.
• Acts as a schedule control signal to identify capacity changes, impediments, and realistic delivery pace.
• Supports release planning, scope negotiation, and risk-based adjustments to commitments.

Purpose of Analysis

Use velocity to assess whether the team is delivering at, above, or below expected pace and to predict how many iterations are needed for a target scope or date. It guides schedule control decisions such as deferring scope, increasing capacity, or changing release plans.

Method Steps

• Select a single sizing unit (e.g., story points or completed items) and keep it consistent.
• At the end of the iteration, total the sizes of work items that meet the Definition of Done.
• Record sprint-by-sprint velocity and compute a rolling average over the last 3–5 iterations.
• Divide remaining scope by the rolling average to estimate iterations needed and potential completion date.
• Review causes of variance (team availability, defects, scope changes), then adjust plans and commitments.
• Communicate updates via burn-up/burn-down charts and release forecasts to stakeholders.

Inputs Needed

• Product backlog with consistent size estimates.
• Definition of Done that determines what counts as complete.
• Iteration length and calendar, including holidays and known absences.
• Historical sprint data (completed items and sizes).
• Current remaining scope and any approved or pending changes.
• Known impediments, risks, and capacity constraints.

Outputs Produced

• Current iteration velocity and rolling average trend.
• Forecast of iterations and date range to complete target scope.
• Updated release plan and stakeholder report on schedule outlook.
• Identified variances, root causes, and corrective or preventive actions.
• Refined commitments for the next iteration based on realistic capacity.

Interpretation Tips

• Wait 3–5 iterations for velocity to stabilize before making strong forecasts.
• Treat it as a capacity indicator, not a productivity scorecard, and avoid team-to-team comparisons.
• Use median or trimmed mean if outliers or scope churn make averages misleading.
• Adjust for known capacity changes (holidays, team changes) rather than forcing the same commitment.
• Rebaseline forecasts when estimation scales change or large scope is added or removed.

Example

A team completes 18, 22, 20, and 21 points over four sprints. The rolling average is about 20 points. With 160 points remaining, the initial forecast is eight more sprints to finish. A new blocker reduces the next two sprints to 16 and 17 points, shifting the rolling average to ~19 and extending the forecast by roughly one sprint. The PM updates the release plan and communicates the impact while tracking the blocker’s removal as a corrective action.

Pitfalls

• Counting partially done work, which inflates velocity and hides schedule risk.
• Changing estimation scales mid-release, breaking historical comparability.
• Using velocity as a target or performance incentive, encouraging gaming and lower quality.
• Ignoring quality debt and defect work that will later slow delivery.
• Making long-range commitments based on a single sprint value rather than a trend.

PMP Example Question

A Scrum team’s average velocity over the last five sprints is 24 points. A key specialist will be on leave next sprint, reducing capacity by 25%. The product owner asks to keep the same commitment to maintain the release date. What should the project manager do?

1. Maintain the commitment to 24 points and ask the team to work extra hours.
2. Lower the next sprint commitment to about 18 points and update the release forecast.
3. Change estimation from story points to hours to get more precise commitments.
4. Add more scope this sprint to compensate for future uncertainty.

Correct Answer: B — Lower the next sprint commitment to about 18 points and update the release forecast.

Explanation: Velocity reflects capacity and should guide realistic commitments. Adjust for known capacity changes and update the schedule outlook, rather than forcing the same target or changing estimation scales.