Why this matters: “how much can we take this sprint” is currently answered with a feeling. These two numbers let you answer it with evidence, and they let you answer “when will it be ready” without lying. They only work if the points feeding them are honest, which is Estimation and Story Points.
Two different numbers
People mix these up constantly, so start here:
- Velocity is history. How many story points this team has actually completed per sprint, measured over past sprints.
- Capacity is availability. How many working hours or days the team has in this specific sprint, after leave, holidays, support duty and meetings.
Velocity tells you what is normal. Capacity tells you why this sprint is not normal.
Velocity: how it works
Take the points from Stories that fully met your Definition of Done in each sprint:
Sprint 1: 24 Sprint 4: 28
Sprint 2: 27 Sprint 5: 26
Sprint 3: 25
Average is about 26. So when planning sprint 6, you plan for roughly 25 to 27 points, not 40 because a deadline is close.
Three rules that make it meaningful:
Only completed work counts. An 8 point Story that is 90% finished contributes zero. Not seven, not four. Zero. It counts in the sprint where it actually completes. This feels brutal the first time and it is the correct behaviour, because the alternative is a velocity number that includes work that does not exist yet.
Use a range, not a point. Real velocity is 24 to 28, not 26. Planning as if it is exactly 26 gives false confidence. When forecasting a date, use the worst recent sprint for the pessimistic case and the best for the optimistic case, and quote both.
It needs three to five sprints to mean anything. Before that, it is noise. A brand new team should plan conservatively and adjust.
Velocity is a forecast, never a target
This is the most important paragraph in the note.
The moment management says “last sprint was 25, this sprint I want 35”, velocity stops measuring anything. It is trivially easy to inflate, everyone knows how, and nobody will admit they are doing it. Your only planning instrument turns into a compliance number within two sprints, and it never recovers.
Microsoft’s own Azure DevOps guidance says the same thing: use velocity for forecasting, not as a key performance indicator. It also means you must never compare two teams by velocity, because points are calibrated per team and a 5 in one team has no relationship to a 5 in another.
If leadership wants to measure delivery health, the DORA measures are far better and much harder to game: deployment frequency, lead time for change, change failure rate, and time to restore. Those describe the system, not the people. Velocity describes one team’s internal unit of size, and it should stay inside the team.
Capacity: why this sprint is different
Velocity assumes a normal sprint. Sprints are frequently not normal.
If your normal velocity is 26 with five people, and this sprint two people are on leave for half of it and one is doing production support full time, planning 26 is simply wrong. Azure DevOps lets you set capacity per person, mark days off, and compare task remaining work against it, which is described in Azure DevOps Setup.
The quick arithmetic version, which is enough for most teams:
Normal team availability = 5 people x 10 days = 50 person days
This sprint = 38 person days (leave, holiday, support rotation)
Availability ratio = 38 / 50 = 0.76
Adjusted plan = 26 points x 0.76 ≈ 20 points
Take 20, not 26, and say why out loud during planning.
Leave room for the work you know is coming
Most teams plan 100% of their available time with feature work, and then act surprised when production issues, urgent customer requests and support questions consume 20% of the sprint. That interruption is not an anomaly. It happens every sprint. It is predictable work that you refuse to plan for.
So measure it. Over three sprints, record the points or hours spent on unplanned work. If it averages 20%, then plan 80% of your velocity for feature work and keep the rest as an interrupt buffer. If the buffer is unused, pull the next ready Story from the backlog, which is easy because you keep ready work available as described in Definition of Ready.
This is not in the Scrum Guide. It is a practical planning technique, and it converts a recurring “we got interrupted again” excuse into a number that everybody has already agreed to.
Forecasting a date without lying
The question “when will this feature be ready” deserves an honest answer, and velocity gives you one.
Remaining scope for the feature: 120 points (estimated at Story level)
Recent velocity range: 24 to 28 per sprint
Feature work share: 80% of velocity = 19 to 22 points per sprint
Sprints needed: 120 / 22 ≈ 5.5 to 120 / 19 ≈ 6.3
Answer: 6 to 7 sprints, assuming scope does not grow.
Two things make that answer trustworthy. First, it is a range. Second, it carries an explicit assumption: assuming scope does not grow. That assumption is the one that always breaks, which is why the discipline in Feedback and Scope Control is what actually determines whether your forecast holds.
Azure DevOps has built in velocity charts and a forecast tool that does this arithmetic for you on the backlog. Useful, but understand the arithmetic first, because the tool cannot tell you that your points are inflated or that your scope is growing weekly.
What velocity tells you when it moves
Velocity is most valuable as a diagnostic, not as a score.
- Steadily falling: usually accumulating technical debt, or a growing manual regression burden, or people being pulled into unplanned work. Investigate, do not push.
- Wildly erratic: usually inconsistent Story sizes, or a Definition of Done that is applied inconsistently, or sprints where scope was added mid flight.
- Suddenly rising a lot: be suspicious. Either the Stories got smaller, or the estimates got bigger, or something is being skipped. Ask which.
- Stable and boring: this is the goal. Boring is what predictable looks like.
One more measure worth watching alongside it: carry over rate, the percentage of committed points not completed. A stable velocity with a high carry over rate means you are consistently over committing, which means you are planning on optimism rather than on this number. The retrospective question that unlocks this, taken from Sprint Planning and Refinement, is not “why did we not finish” but “which of the four causes in Estimation and Story Points was it, and what is the evidence”.