DEV Community

keyur shah
keyur shah

Posted on

Velocity vs Capacity

When sprint planning rolls around, two numbers often get tangled: velocity and capacity. They look alike, but they serve opposite purposes—one looks backward, the other forward. Understanding the distinction helps teams set realistic commitments and keep stakeholders honest.

Velocity

  • Historical output – Velocity is the average story points your team has completed over the last few sprints.
  • A trailing indicator – It tells you what actually happened, not what will happen. Because it’s derived from past performance, it’s useful as a baseline but not a guarantee for the next sprint.

Capacity

  • Available time this sprint – Capacity measures the total person‑hours or story points the team can realistically spend, after accounting for vacations, holidays, on‑call duties, and other non‑project work.
  • A forward‑looking input – Use capacity to sanity‑check the amount of work you plan to pull in. If the team has less time than usual, the commitment should shrink accordingly.

How They Interact

  • Velocity sets the baseline – Start with your average velocity as a rough guide for how much work you could handle.
  • Capacity adjusts it – If the upcoming sprint has reduced capacity (e.g., two developers are on leave), plan below the average velocity. Conversely, a sprint with extra headcount can allow you to stretch a bit beyond the historical average, but only within a reasonable range.

Common Mistake

  • Committing to average velocity always – Ignoring that this sprint has three people on leave leads to over‑commitment and spillover.
  • Chasing a velocity target – Inflating estimates or adding hidden work just to hit a number turns velocity into a performance metric rather than a planning tool.

Do / Avoid

Do

  • Adjust commitment down for known capacity dips.
  • Use velocity as a range, not a fixed target.
  • Track both velocity and capacity separately on the sprint dashboard.

Avoid

  • Don’t commit to full average velocity during a low‑capacity sprint.
  • Don’t use velocity as a performance metric for individuals.
  • Don’t let stakeholders treat velocity as a promise.

Keep velocity as the historical compass and capacity as the current weather report; together they guide the team to realistic, sustainable sprint commitments.


Book a call

Top comments (0)