Sprint capacity vs. velocity: when to use each

Capacity looks at the time and people available next sprint. Velocity describes past delivery. Use both without treating points as hours.

Two different planning questions

MeasureQuestionUseful input
CapacityWhat can we reasonably take on this sprint?Availability, PTO, allocation, required skills
VelocityWhat have we actually completed?Completed points from comparable past sprints

Capacity is forward-looking. Velocity is historical. Neither guarantees delivery. A sprint with the same number of people can still have a different risk profile if an essential specialist is unavailable.

Use history as a reference, not a promise

Suppose a team completed 28, 32, and 30 points in three comparable sprints. Its arithmetic average is 30. A planning conversation can start there, then consider absences, new work, and dependencies. Carry-over work should not be treated as completed delivery merely because it was planned.

If you decide reduced availability calls for a 24-point target, enter 24 in sprint-specific mode. Entering 30 and adding PTO will not automatically turn it into 24 in that mode. Member-based mode instead adjusts the member baselines you provide.

Avoid double discounts

If a baseline already reflects a person’s normal part-time schedule, applying another 0.5 allocation multiplier for that same schedule would discount it twice. Similarly, do not subtract the same absence as both PTO and reduced allocation. Write down what the baseline includes.

Points are local estimates

The planner does not derive points from hours, compare individuals, or calculate a team’s historical velocity automatically. Choose baselines through a team discussion. A change in estimation scale, team membership, or sprint duration makes older averages less comparable.

Choose a workflow

Continue with the worked capacity example and PTO planning guide.