How do you estimate a team's velocity correctly?
Velocity = the average story points shipped in the last 3-5 closed sprints. You do not estimate velocity in theory — you measure it. And you do not use it as a target (Goodhart's law), you use it as a planning input.
Velocity is one of the most abused metrics in Scrum. Teams turn it into a KPI ("we need to grow velocity") and start inflating story points — meaning evaporates. Good velocity is descriptive (what we actually ship), not prescriptive (what we should). It serves realistic planning, not team evaluation.
1. Velocity is measured, not estimated
There is no such thing as "theoretical velocity". A team's velocity is the average of story points closed with Definition of Done satisfied across the last 3-5 sprints. Before you have 3 closed sprints, you have no velocity — you estimate via t-shirt sizes or reference stories.
A new team calibrates over 4-6 sprints. During that period planning is more conservative and adjusts after every retro. Stakeholders need to be told explicitly: "The first 5 sprints are a calibration window — do not evaluate velocity on them."
2. Story points are relative, not absolute
A story point is not "a day of work". It is "the complexity of a reference story". The team picks a medium story, calls it 3 SP, and estimates everything else relative to it: "This is about twice that", "This is half".
That means velocity is not comparable across teams. Team A ships 35 SP/sprint, Team B ships 50 SP/sprint — it does not follow that B is faster. Their SP calibration is different. Managers who try to compare velocity across teams are making a fundamental mistake.
3. Velocity is not a KPI — it is an input
The most abused anti-pattern: "This quarter we want velocity 45". The moment velocity becomes a target, the team starts inflating estimates. 3-SP stories become 5 SP. The sprint closes at higher velocity, but delivery does not actually grow. Goodhart's law: when a metric becomes a target, it stops being a good metric.
Good velocity is used for planning: "Next sprint's capacity is 35 SP (historical velocity) × 0.85 (absences and time reserved for emergencies) = 30 commit-able SP". That is it. Not for bonuses, not for OKRs, not for the CEO report.
4. Adjust for real sprint capacity
Historical velocity assumes normal capacity. If next sprint loses 25% of capacity (absences, production emergencies, training), drop the commit by 25% — or rather adjust effective capacity, not the abstract velocity.
4myprojects does not know who is away — that cut is yours to make. What it gives you are the numbers to make it on: real velocity over recent sprints and each person's load from the tasks already assigned. Teams that skip the step commit as if the sprint were normal — and then are surprised when delivery slips.
5. Cycle time is often more useful than velocity
For scope predictability, cycle time (the average time from "In Progress" to "Done") is more informative than velocity. You can tell a customer: "85% of our tasks close in 5 days or less." That is a promise you can keep.
Velocity answers "how much can we ship?", cycle time answers "how long does one request take?". Support, ops or unpredictable-demand teams are better served by cycle time. Teams with planned sprints use velocity for capacity, cycle time for SLAs.
Velocity auto-calculated in 4myprojects
Historical velocity across the last 5 sprints, each person's load from the tasks already assigned, a burndown for the current sprint, on-board cycle time with p50/p85/p95 distribution — no SQL or Excel export needed.