Understanding Scrum Velocity As A Capacity Forecast, Not A Productivity Measure

What is Velocity in Agile Scrum

Velocity in Agile scrum methodologies refers to the amount of work a scrum team can handle in a single sprint iteration. It is calculated by summing the story point values for all fully completed user stories in an iteration. Velocity provides insight into the rate at which a team delivers working, tested software. Some key attributes of velocity include:

Expressed in units of story points completed per sprint iteration
Fluctuates somewhat between sprints based on scope variability
Tends to stabilize over 3-5 sprints for mature teams
Forecasts capacity but does not assess productivity

Velocity reflects the team’s bandwidth in a repeatable process. Once stabilized after several sprints, it can predict the amount of features or user stories (measured in story points) that the team can reliably complete in upcoming sprints.

Velocity as a Measure of Capacity, Not Productivity

An important distinction is that velocity represents the team’s bandwidth – how much work they have capacity to complete per sprint. It does not directly measure the team’s productivity. While related, capacity and productivity have subtle differences:

Table of Contents

Capacity represents total ability to deliver working software in a sprint
Productivity represents how efficiently that ability is translated into value

For example, a team’s capacity might enable completing 50 story points per sprint. Their productivity might influence whether those 50 story points translate to higher business value features versus low value features. In this way, velocity tells us how much a team can complete, but not necessarily how effective they are at maximizing business value.

How to Use Velocity for Planning and Forecasting

Once a team’s velocity has stabilized, it can be leveraged for release planning and forecasting. Some examples include:

Backlog refinement – The product owner can structure the backlog based on velocity to see roughly how many sprints are needed to complete initiatives
Release planning – Management can forecast release dates and set milestones based on the team completing features at the current velocity
Sprint planning – The scrum team knows their reliable capacity and can pull the highest priority backlog items into the sprint that match their velocity

It’s worth noting that velocity represents an average over time. Individual sprint results may fluctuate above and below the velocity line. The key is looking at the overall velocity trend across the most recent 3-5 sprints to conduct planning.

Common Misconceptions Around Velocity

Some common misconceptions that development teams have around velocity include:

Higher velocity is better – Faster velocity often means technical debt and defects are accumulating
Lower velocity reflects low productivity – Could represent appropriate quality focus or investments to raise velocity long-term
Include partially complete work – Inaccurately inflates velocity leading to poor forecasting

The key is not gaming velocity through corners cutting or scrambling. Smooth, sustained velocity that completes stories fully with good engineering practices should be the goal. Quality, sustainability, and predictability trump speed for speed’s sake.

Example Velocity Calculation for a Scrum Team

Let’s walk through a sample velocity calculation for a 5 person Scrum team across a 6 sprint time period:

Sprint	Story Points Completed
1	32
2	40
3	50
4	40
5	55
6	53

To calculate velocity, we sum up the completed story points per sprint. So Sprint 1 had 32 completed story points. Sprint 2 had 40 completed story points, and so on through Sprint 6. This totals to 270 completed story points over 6 sprints.

To find overall velocity, we take the total story point completion and divide it by the number of sprints. So velocity for this team example would be 270 total story points / 6 sprints = 45 story points per sprint.

We can see their initial velocity was unstable (varying from 32 to 50), but it stabilized between Sprints 3 to 6 (from 50 to 53 points per sprint). This velocity figure represents this team’s capacity – on average they complete about 45 stories points worth of user stories each sprint.

Maximizing Value Delivery Within Team Capacity

While velocity provides insight into throughput capacity, the team must still maximize business value delivered within that fixed bandwidth each sprint. Some techniques include:

Focusing on highest priority backlog items aligned to company strategy
Breaking down large initiatives into smaller value-focused increments
Optimizing sprint execution to deliver completeness over partial progress

By combining velocity-based planning and value-focused execution, Scrum teams can reliably deliver incremental business value over time.

Recalibrating Velocity When Team Composition Changes

Velocity fluctuates any time there is a substantive change in the team’s composition or bandwidth. Some examples that impact velocity include:

Team members joining/leaving
Team training/vacation/leave that disrupts sprint execution
Team taking on additional initiatives decreasing sprint focus

In these situations the past velocity no longer reflects the new team composition. The velocity must be recalibrated over 2-3 sprints once the disruption has stabilized. This emphasizes velocity’s nature as a capacity forecast that must be rebaselined as team bandwidth changes over time.

Related Metrics: Burn-Up Charts and Burn-Down Charts

While velocity focuses on throughput, burn-up and burn-down charts provide complementary visibility into progress towards a specific sprint or release goal:

Burn-Up Charts – Show total story points completed over time for a given release or project
Burn-Down Charts – Show remaining story points or effort left to complete all planned work for a sprint

Used together, these metrics provide richer insight into completion rates, scope change, and progress to plan. Velocity stabilizes output expectations, burn charts visualize that output against a specific plan.