What is Velocity in Agile?

How to Calculate Velocity

Velocity calculation requires two things: a consistent unit of measurement and counting only completed work.

• Choose a unit — story points (estimated effort), hours (actual tracked time), or task count
• Sprint 1 completion: 32 story points
• Sprint 2 completion: 28 story points
• Sprint 3 completion: 36 story points
• Average velocity: (32+28+36) ÷ 3 = 32 story points per sprint
• Next sprint planning: commit to approximately 32 story points of backlog items

Using Velocity for Sprint Planning

Velocity makes sprint planning a data-driven decision rather than a gut-feel commitment. Instead of asking "how much do we think we can do?" (which always leads to over-commitment), you ask "what does our velocity say we can do?"

Velocity also enables project-level forecasting. If a backlog has 320 story points remaining and the team's velocity is 32 per sprint, the project has approximately 10 sprints (20 weeks) remaining. This is a forecast, not a guarantee — scope will change — but it gives stakeholders a realistic picture.

Velocity Mistakes to Avoid

Using velocity as a performance metric — velocity is a planning tool. Comparing velocities between teams or pressuring a team to increase velocity leads to inflated story points and gaming the system.

Counting incomplete work — velocity only includes items that meet the Definition of Done. A story that's 90% done counts as zero.

Expecting velocity to be constant — velocity varies naturally. A sprint with a holiday, a team member sick, or unusually complex work will have lower velocity. Plan based on average, not best-case.

Using velocity without story points — if your team estimates in days and tracks in hours, the math doesn't translate cleanly. Pick one unit and use it consistently.

Velocity After Team Changes

Team changes — someone joining, someone leaving, someone moving to a different project — invalidate historical velocity data. A velocity of 40 story points per sprint based on 6 sprints with a team of 5 tells you nothing reliable about what a team of 4 can do next sprint.

When someone leaves, velocity will drop. If the departing person handled 20-25% of the team's work, expect velocity to drop proportionally — possibly more if their work required specialized skills nobody else has.

When someone joins, velocity typically drops before it rises. The new person needs onboarding. The existing team spends time helping them. Sprint 1 and Sprint 2 after a new hire often come in below pre-hire velocity.

The practical approach: treat team changes as a velocity reset. Run 3 sprints with the new team configuration before using velocity for meaningful planning commitments. In the interim, plan conservatively — commit to 70-80% of your previous velocity until you have new data.

• Any team composition change invalidates current velocity data for planning
• New hire: expect velocity to dip for 2-3 sprints before it rises
• Departure: velocity drops proportionally to that person's workload share
• Run 3 sprints post-change before using velocity for firm commitments

Using Velocity for Release Planning

Release planning answers the question: when can we ship the next major version? Velocity gives you the data to answer it mathematically.

The calculation: count the story points in the features committed to the release. Divide by the team's average velocity. The result is the number of sprints needed. Multiply by sprint length to get a date.

Example: the release has 280 story points of committed features. The team's velocity is 35 points per sprint. 280 / 35 = 8 sprints. At 2-week sprints, that's 16 weeks — a release date with a data-backed rationale.

When someone asks 'can we move the release up by a month?', you can answer with specifics: 'That removes 4 sprints, representing about 140 story points. Which features should we cut?'

Two caveats: first, velocity-based release plans assume roughly stable velocity. If the team's velocity has high variance, give a range. Second, scope always grows during a release cycle — build a 15-20% scope buffer into release planning.

• Release date = (committed story points / velocity) × sprint length
• Use this as a credible, data-backed response when stakeholders ask about timelines
• High velocity variance: give a range, not a single date
• Scope grows during a release cycle — plan with a 15-20% growth buffer

Velocity for Non-Software Teams

Velocity originated in software development, but the concept — track how much the team completes per time period and use it to plan — applies to any team with repetitive, estimable work.

For a marketing team: velocity in tasks completed per week or content pieces shipped per sprint. For a design studio: velocity in design hours per sprint. For an operations team: velocity in tickets resolved per week.

For an agency team doing client work across multiple disciplines, hours are often the most reliable unit. Track how many billable hours the team completes per week across all projects. Average over 4-6 weeks. Use that as your planning baseline: if the team averages 180 billable hours per week and a project needs 360 hours, plan for 2 weeks.

Non-software teams often resist velocity tracking because it feels like monitoring. Velocity is a planning input, not a performance metric. The team benefits from it — accurate capacity planning means less overcommitment and fewer crises.

• Choose a consistent unit: tasks per week, deliverables per sprint, or billable hours per week
• Agencies: hours completed per week is often cleaner than story points
• Average 4-6 periods before using velocity for planning commitments
• Position it as a planning tool, not a measurement of individual performance