Release Velocity Calculator
Track releases per week over time and detect whether release velocity is accelerating or decelerating.
Inputs
Number of releases shipped in the previous measurement period.
Number of releases shipped in the current measurement period.
Length of each measurement period, used to normalize to releases/week.
Current Release Velocity
2.75releases/week
Trend
Accelerating
Change vs Previous Period
37.5%
Previous Release Velocity
2.00releases/week
Step by step
Previous velocity: releases ÷ period weeks
8 ÷ 4
= 2.00 releases/week
Current velocity: releases ÷ period weeks
11 ÷ 4
= 2.75 releases/week
Change: current − previous
2.75 − 2.00
= 37.5% (Accelerating)
How it works
Release velocity normalizes release counts from two consecutive periods to a common releases-per-week rate and compares them to detect a trend: change% = (current_velocity − previous_velocity) ÷ previous_velocity × 100. A change beyond ±5% is classified as accelerating or decelerating; smaller fluctuations are treated as stable, since release counts over short periods naturally have some noise.
Formula
velocity = releases / time_period_weeks
- releases
- Number of releases shipped
- time_period_weeks
- Length of measurement period (weeks)
Frequently Asked Questions
Why normalize to releases per week instead of comparing raw counts?
Comparing raw release counts across periods of different lengths (or with different numbers of working days/holidays) can be misleading — normalizing to a rate makes the comparison meaningful regardless of exact period length.
What's a healthy release velocity trend?
A gently accelerating or stable trend generally reflects a maturing delivery pipeline; a sharply decelerating trend can signal growing technical debt, testing bottlenecks, or an increasingly risk-averse release process worth investigating.
How does this differ from the DORA deployment frequency metric?
Deployment frequency measures a single period's rate against DORA's performance tiers; release velocity specifically tracks the trend between two periods to answer 'are we speeding up or slowing down,' which deployment frequency alone doesn't capture.
Should hotfixes count as releases in this calculation?
Be consistent — if your deployment frequency metric counts all production deployments including hotfixes, use the same definition here, since mixing definitions between periods would create a false trend signal.
You might also need
- Sprint Burndown CalculatorCommonly used together
- Team Capacity CalculatorCommonly used together
- Lead Time for Changes CalculatorCommonly used together
- Deployment Frequency CalculatorCommonly used together
- Platform Reliability Score CalculatorAlso in DevOps Metrics & DORA
- DevOps Maturity Score CalculatorAlso in DevOps Metrics & DORA