When a Scrum team sits down for sprint planning, two numbers often get tossed around as if they were interchangeable: velocity and capacity. Understanding the distinction—and how they complement each other—prevents over‑commitment, keeps forecasts realistic, and protects the team from unhealthy pressure to “hit a number.”
Velocity
- Historical output – Velocity is the average story‑point count the team has actually completed in past sprints.
- A trailing indicator – It tells you what happened, not what will. Because it is derived from completed work, it reflects the team’s proven delivery rate under normal conditions.
Velocity is a useful baseline because it grounds planning in reality. However, it is static; it does not account for upcoming holidays, sick days, or other temporary changes to the team’s makeup.
Capacity
- Available time this sprint – Capacity is the sum of the team’s usable hours or story points after adjusting for leave, holidays, on‑call duties, and any other known constraints.
- A forward‑looking input – It is used to sanity‑check the commitment, ensuring the planned work fits within the actual bandwidth for the upcoming sprint.
Capacity is a dynamic figure that changes sprint‑to‑sprint. It tells the team how much they can realistically take on given the current calendar.
How They Interact
- Velocity sets the baseline – Start with the average velocity as a rough guide for how much work the team typically delivers.
- Capacity adjusts it – If the upcoming sprint has reduced capacity (e.g., three members are on leave), the team should commit to fewer story points than the velocity suggests. Conversely, a sprint with extra capacity may allow a slight stretch beyond the average.
Think of velocity as the “what we usually do” and capacity as the “what we can do this time.” The intersection of the two yields a healthy commitment range.
Common Mistake
- Committing to average velocity always – Ignoring that this sprint has three people on leave leads to over‑commitment and unfinished work.
- Chasing a velocity target – Inflating estimates or adding “buffer” stories just to hit a pre‑set number turns velocity into a performance metric rather than a planning tool.
Both pitfalls erode trust, create burnout, and distort the data that velocity is supposed to provide.
Do / Avoid
Do
- Adjust commitment down for known capacity dips.
- Use velocity as a range, not a fixed target; plan within a band (e.g., ±10 %).
- Track both velocity and capacity separately on the sprint dashboard for transparency.
Avoid
- Don’t commit to the 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; it is a planning aid, not a guarantee.
Takeaway: Use velocity as a historical reference and capacity as the real‑time constraint; together they keep sprint commitments realistic and sustainable.
