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 (PTO and on-call) = 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 (PTO, on-call, training), drop the commit by 25% — or rather adjust effective capacity, not the abstract velocity.
4myprojects computes this automatically from approved PTO and the on-call rotation. Teams doing it by hand forget to do it and 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, capacity adjusted for PTO, automatic commit suggestion at planning, on-board cycle time with p50/p85/p95 distribution — no SQL or Excel export needed.