Velocity

Velocity is a central concept in agile frameworks such as Scrum and refers to the amount of work a development team can complete in a sprint or iteration. This measure is usually expressed in story points, but can also be based on other units such as the number of backlog items or working hours.

Definition and Calculation

Velocity is defined as the sum of the story points of all user stories (or other backlog items) that were fully completed in a sprint and meet the Definition of Done. Stories that were not fully completed do not count toward velocity, regardless of how far along they are.

Calculation typically takes place after each sprint:

1. Identify all completed user stories in the sprint
2. Sum the story points of these stories
3. Document the result as the sprint velocity

For a meaningful velocity measurement, multiple sprints should be considered, with the following calculations being common:

• Average Velocity: Sum of story points over multiple sprints divided by the number of sprints
• Median Velocity: The middle value of all sprint velocities, less susceptible to outliers
• Rolling Average: Average of the last n sprints (typically 3-5) to better capture current trends

Purpose and Benefits of Velocity

Velocity serves several important purposes in agile projects:

Sprint Planning

• Enables teams to plan a realistic amount of work for the next sprint
• Prevents overloading the sprint with too many stories
• Promotes reliable commitments to stakeholders

Release Planning

• Helps forecast when features or releases will be completed
• Enables calculation of how many sprints are needed to implement a product backlog
• Supports data-driven decisions about scope and timeframe

Continuous Improvement

• Provides a metric to measure team performance over time
• Enables identification of trends and patterns
• Helps evaluate the impact of process changes

Factors Influencing Velocity

A team's velocity is influenced by numerous factors:

Team Factors

• Team Size and Composition: Changes in team size or skill mix directly affect velocity
• Team Maturity: Teams typically go through the stages of forming, storming, norming, and performing with increasing velocity
• Availability: Vacation, illness, or part-time work reduce available capacity
• Learning and Growth: With increasing experience and improved skills, velocity often rises

Process Factors

• Definition of Done: Stricter criteria can reduce velocity short-term but increase quality
• Technical Debt: Accumulation of technical debt can reduce velocity over time
• Sprint Length: Changes in sprint duration require recalibration of velocity
• Story Splitting Practices: How teams split stories affects their size and thus velocity

External Factors

• Interruptions: Unexpected requests, production issues, or meetings
• Technical Infrastructure: Issues with development environments or CI/CD pipelines
• Dependencies: Waiting on external teams or suppliers
• Organizational Context: Restructurings, strategy changes, or budget cuts

Common Misconceptions and Pitfalls

The following misconceptions should be avoided when applying the velocity concept:

Velocity as Performance Evaluation

Velocity was never designed as a measure of productivity or for evaluating individual team members. It should not be used to:

• Compare teams with each other (each team has its own scale)
• Evaluate the performance of team members
• Determine bonuses or promotions
• Put pressure on teams to artificially increase velocity

Velocity Inflation

When velocity is misused as a performance metric, it often leads to:

• Overestimation of story points ("story point inflation")
• Focus on speed rather than quality
• Neglect of technical debt
• Manipulation of measurements

Velocity as a Promise

Velocity is a planning tool, not a promise or contract. It should not be:

• Communicated as a guaranteed delivery quantity
• Treated as an immutable commitment
• Seen as a goal in itself

Best Practices for Working with Velocity

The following practices are recommended for a healthy use of velocity:

Measurement and Tracking

• Track velocity across multiple sprints, not just single sprints
• Visualize velocity trends, e.g., with velocity charts
• Document contextual factors that might explain outliers
• Regularly calibrate the estimation scale to ensure consistency

Planning with Velocity

• Choose a conservative approach for sprint planning (e.g., 80% of average velocity)
• Include buffer for uncertainties in release planning
• Be cautious with initial velocity values for new teams
• Consider velocity as one of several factors in decision-making

Communication

• Explain the purpose and limitations of velocity to stakeholders
• Communicate velocity as a planning tool, not a performance metric
• Create transparency about factors that influence velocity
• Present forecasts based on velocity ranges rather than single numbers

Alternative and Complementary Metrics

Velocity should not be the only metric teams track. Complementary metrics include:

• Cycle Time: Time from picking up a task to its completion
• Lead Time: Time from request to delivery
• Throughput: Number of completed items per unit of time
• Defect Escape Rate: Proportion of defects discovered after the sprint
• Team Happiness: Satisfaction and engagement of the team
• Customer Satisfaction: Satisfaction of stakeholders with delivered increments

Velocity in Different Agile Frameworks

Velocity in Scrum

In Scrum, velocity is an important planning tool for Sprint Planning and Release Planning. Scrum teams frequently use Burndown Charts or Burnup Charts to visualize progress within a sprint and track velocity across multiple sprints.

Velocity in Kanban

Pure Kanban teams traditionally do not use story points and therefore no velocity in the classic sense. Instead, they focus on throughput, cycle time, and work in progress (WIP). Hybrid Scrumban approaches can, however, combine elements of both systems.

Velocity in SAFe

In the Scaled Agile Framework (SAFe), velocity is used both at the team level and aggregated at the program level. SAFe uses velocity for PI Planning (Program Increment Planning) and for capacity planning for multiple teams within an Agile Release Train.