Velocity
Velocity measures the total amount of work completed by a team during a fixed time window. It reflects the team’s actual throughput and is commonly used to improve sprint planning, track delivery patterns, and forecast future capacity.
Calculation
Completed work typically includes any tasks, stories, or issues that meet the team’s Definition of Done by the end of a reporting period. The measurement window is most often a sprint but may also be a week, month, or custom cadence in non-sprint workflows. Work units are usually story points, ticket count, or time-based estimates. What matters most is using the same unit and cadence consistently.
This metric is calculated by summing the amount of work completed during the defined time period:
velocity = total completed work units per period
Goals
Velocity helps teams plan more effectively by providing a baseline for what they can typically complete. It answers questions like:
- How much work do we realistically deliver per cycle?
- Are we maintaining a stable pace or trending up or down?
- Can we forecast future delivery timelines based on past output?
When interpreted correctly, velocity helps improve delivery confidence and prevent overcommitment. For practical forecasting applications, see The Agile Alliance's definition of velocity in Agile teams.
Variations
Velocity is sometimes referred to as Sprint Velocity, especially in Scrum. In non-sprint models, it may be tracked weekly, monthly, or by release cycle. Other variations include:
- Average Velocity, calculated across the last 3–5 iterations to normalize short-term variance
- Planned vs. Actual Velocity, comparing committed versus completed work to assess planning accuracy
- Velocity per contributor, sometimes used for capacity planning, but not for performance evaluation
- Normalized Velocity, which adjusts for team size or partial availability
Velocity can be measured in points, tasks, story count, or time, all valid approaches as long as the baseline remains stable across time.
Limitations
Velocity reflects quantity of output not value, complexity, or predictability. A higher number doesn’t necessarily mean the team is delivering more valuable work.
It also shouldn’t be used to compare teams. Different estimation scales, workflows, or work types make cross-team comparisons misleading.
To better interpret velocity and align it with delivery confidence, use it alongside:
| Complementary Metric | Why It’s Relevant |
|---|---|
| Planning Accuracy | Shows how closely committed scope aligns with actual delivery. |
| Sprint Rollover Rate | Reveals whether incomplete work is distorting velocity and forecasting. |
| Work in Progress (WIP) | Helps identify if multitasking or delivery drag is limiting completed output. |
Optimization
Improving velocity is about making work more finishable and aligning delivery rhythm with planning habits.
-
Break down work more effectively. Split large stories into smaller, independent units that can be completed and counted within the same window.
-
Improve ticket readiness. Ensure backlog items meet the Definition of Ready before entering the sprint or cycle. This reduces confusion and mid-cycle rework.
-
Avoid multitasking. High WIP slows completion. Focus on finishing in-progress work rather than starting more tasks, especially near the end of a time window.
-
Stabilize team inputs. Changes in staffing, unplanned interrupts, or inconsistent sprint lengths distort velocity trends. Track availability explicitly and adjust capacity accordingly.
-
Use velocity for planning, not pressure. Velocity is a useful planning signal, not a target to maximize. Healthy teams improve predictability by focusing on steady, achievable throughput, not by inflating effort estimates or gaming story points.
Velocity is only as useful as the consistency behind it. When tracked responsibly, it helps teams forecast confidently, plan realistically, and maintain sustainable delivery momentum.
