Velocity | Agile Scrum Master
Velocity is a team-specific measure of how much work is completed in an iteration and can be used to forecast near-term delivery when conditions are stable. It is useful for planning with uncertainty when it is based on a consistent Definition of Done and is treated as empirical input, not a performance target. Key elements: stable team and backlog, consistent sizing approach, completed work only, trend-based forecasting ranges, and clear rules that prevent comparing velocity across teams. Velocity should be interpreted as a trend and can be replaced by throughput when sizing is inconsistent.
What Velocity measures
Velocity is the amount of work a team completes in a fixed iteration, often a Sprint. Velocity is typically expressed in the same units used for relative sizing, such as story points. The purpose of Velocity is forecasting: it helps a team reason about how much work they can likely complete in the next iteration and how a set of work might progress over time.
Velocity is a team-local, context-dependent signal. It is only meaningful when the team keeps a consistent sizing approach and a stable Definition of Done, and it should be interpreted as a trend with variability rather than a commitment or a productivity score.
Purpose and Importance
Used well, Velocity supports planning under uncertainty by making assumptions explicit, using real delivery evidence, and updating forecasts as conditions change. The goal is better decisions and learning, not better numbers.
- Forecasting - Uses recent delivery evidence to forecast near-term completion, ideally as a range.
- Planning - Helps select work for an iteration while protecting the Sprint Goal and quality.
- Trend analysis - Surfaces shifts in delivery capability so the team can inspect causes and adapt.
- Expectation management - Enables trade-off conversations based on options: scope, sequence, or capacity.
- Continuous improvement - Prompts system-level learning about slicing, WIP, dependencies, and rework.
Key Characteristics
Velocity reflects a system of work, not just team effort. Changes in workflow policies, dependencies, and quality practices can move the trend, so interpretation should always include context.
- Team-specific - Applies to one stable team with shared working agreements and a consistent sizing meaning.
- Relative measure - Expresses completed size in the team’s own scale, not time or “productivity”.
- Historical basis - Useful across several iterations to smooth noise, not to “promise” a single iteration outcome.
- Done-only - Counts only work that meets the Definition of Done, preserving transparency and limiting hidden rework.
How to calculate Velocity
Velocity is calculated using only completed work that meets the team quality standard. Counting partially done work breaks transparency and shifts attention from outcomes to appearances.
- Use completed items only - Count only work that meets the Definition of Done for the iteration.
- Use a consistent sizing basis - Keep sizing rules stable so the meaning of a point does not drift.
- Track over multiple iterations - Use several iterations to reduce noise and avoid reacting to outliers.
- Prefer ranges over single values - Communicate a range with variation, not a single guaranteed number.
- Record context changes - Note disruptions like team changes, incidents, or policy shifts that affect interpretation.
Stability usually improves when work is sliced smaller, backlog refinement reduces ambiguity, WIP is limited, and quality remains non-negotiable.
How Velocity supports forecasting and planning
Velocity supports near-term planning by grounding decisions in evidence. The team inspects recent outcomes, adapts selection for the next iteration, and refreshes forecasts as new information arrives.
- Iteration planning - Use recent trends to select a realistic amount of work toward a goal.
- Release forecasting - Use ranges to estimate how many iterations are likely for a scope slice, not a fixed date.
- Scenario discussion - Explore options by changing scope, sequence, or capacity rather than demanding certainty.
- Risk exposure - Make overload visible early and enable timely trade-offs before commitments become failures.
- Learning cadence - Update forecasts frequently and keep assumptions explicit to maintain trust.
When uncertainty is high, forecasts are stronger when combined with throughput, cycle time, or probabilistic approaches such as Monte Carlo, rather than forcing point-based certainty.
Conditions that make Velocity unreliable
Velocity becomes unreliable when key system conditions are unstable. Erratic trends are often a symptom of unclear work, heavy dependencies, inconsistent quality, or shifting policies.
- Inconsistent Definition of Done - Counting partially done work creates artificial spikes and hides rework.
- Large or unclear items - Poor slicing increases variance and makes forecasting less dependable.
- High dependency queues - Waiting on external teams decouples effort from completion.
- Team instability - Frequent changes in staffing, tools, or domain knowledge reduce comparability over time.
- Size scale drift - Reinterpreting points changes the meaning of the trend and invalidates past data.
In these conditions, teams often get better predictability from flow metrics and distributions than from size-based trends.
Velocity and empirical planning in Scrum
Velocity is commonly used in Scrum, but it is not required. Scrum’s empirical foundation is transparency, inspection, and adaptation, with the usable Increment and progress toward the Sprint Goal as primary evidence.
If the trend improves while defects, rework, or spillover increase, the system is deteriorating. Empirical planning favors surfacing that reality early and adapting the work and policies, rather than protecting a number.
Alternatives to Velocity
Teams can forecast without Velocity, especially in flow-based systems or when sizing is inconsistent. These alternatives rely on observed delivery and variability rather than estimated size.
- Throughput - Forecast using completed items per period without story points.
- Cycle time - Forecast how long work takes from start to finish using historical distributions.
- Lead time - Forecast from commitment to delivery, useful for end-to-end responsiveness.
- Work item aging - Detect stuck work early and reduce delays by managing WIP and dependencies.
- Probabilistic forecasting - Produce likelihood-based ranges rather than deterministic dates.
Common misuse and practical guardrails
This metric is most harmful when it is treated as a target or used for comparisons. That shifts behavior toward gaming (points, slicing optics, quality shortcuts) and away from outcomes, learning, and system improvement.
- Using it as a performance target - Looks like leaders demanding “higher numbers” or using the metric in evaluation; it drives gaming and hides problems. Keep it as a planning input and use outcomes, quality, and reliability evidence for performance discussions.
- Comparing teams - Looks like ranking teams or aggregating trends across teams; it produces false conclusions because scales differ. Compare customer outcomes, delivery reliability, and flow measures instead.
- Gaming the size - Looks like points inflating without increased value delivered; it breaks forecasting and trust. Decouple estimation from incentives and validate with usable increments and stakeholder feedback.
- Counting unfinished work - Looks like credit for “almost done” items; it hides rework and reduces transparency. Count only Done work and make blocked work visible early.
- Ignoring variability - Looks like single-date promises from a noisy trend; it increases disappointment and escalation. Communicate ranges, show assumptions, and refresh forecasts as new evidence arrives.
Velocity is a team-specific measure of completed work per iteration used for forecasting and planning, not for comparing teams or driving performance safely