Velocity
The average amount of work (typically measured in story points) a team completes per sprint. It's the primary forecasting metric for roadmap planning and capacity allocation.
What is Velocity?
Velocity is the rate at which a team converts backlog items into completed work. If a team completes 28 story points per sprint consistently, their velocity is 28. This single number—boring as it is—becomes the foundation for roadmap forecasting: 28 points per sprint × 13 sprints = 364 points per year.
Velocity isn’t a measure of productivity or skill. It’s a measure of capacity within your specific context: your team size, technical stack, organizational constraints, and definition of done. Team A might have 45-point velocity and Team B 22 points with equal skill; the difference reflects dependencies, architecture, and institutional friction.
Reading Velocity Signals
Stable velocity (variance below 10%) signals predictability. You can commit to roadmaps with confidence. Declining velocity (weeks 1-8: 32, 29, 28, 24, 19…) signals trouble: technical debt accumulation, rising defect rates, loss of focus, or organizational dysfunction. Spiking velocity in one sprint followed by collapse usually indicates a one-time gift (like a completed dependency) rather than sustainable change.
Velocity is sensitive to definition of done. If your team stops testing code before the sprint ends, velocity artificially inflates—but so do post-release defects. Changing what “done” means breaks velocity as a forecasting tool. This is why definition of done is non-negotiable: it’s the contract that makes velocity meaningful.
Velocity as a Constraint
Roadmap planning begins with velocity. If you have 90 points of committed features and 30-point velocity, that’s 3 sprints. If organizational pressure suggests you can ship in 2 sprints, something has to give: scope, quality, or team size. Pretending velocity is flexible leads to late delivery and burnout.
Some teams try to “increase velocity” through will alone. The only sustainable way to increase velocity is to remove constraints: fewer dependencies, better tools, clearer specification, reduced technical debt, or more experienced engineers. Exhorting teams to work faster is vacuous.
Why It Matters for Product People
Velocity is your sanity check on roadmap feasibility. Before committing to investors, customers, or boards, calculate: How many points of work? What’s team velocity? How many sprints will delivery take? If the answer exceeds your timeline, negotiate scope or reset timelines. The alternative is chronic late delivery and eroded trust.
Track velocity trends, not individual sprints. One sprint with 18 points (everyone was sick) doesn’t change your forecast. Six months of declining velocity from 35→32→30→26 signals systemic issues requiring investigation.
Related Concepts
Velocity feeds sprint planning (how much to commit) and roadmap planning (when you’ll finish). It also connects to throughput (how many features ship) and retention metrics—teams with healthy, stable velocity tend to retain talent better than chronically over-committed teams.