How much work can your team actually deliver per sprint? Velocity answers that with data, not the optimism of the last sprint planning session.
Velocity measures how much work a team actually finishes in a sprint, usually in estimation points (story points) attached to delivered user stories. It's neither a goal nor an individual performance metric: it's a rolling average used only to plan future sprints realistically.
A team that delivers 30 points on average per sprint can commit to roughly 30 points at the next sprint planning — not 45 because the Product Owner hopes to go faster. The Scrum framework doesn't formally define velocity (like the user story, it's a derived practice, not an official event), but it's used by nearly every Scrum team in the world.
A half-finished story doesn't count toward velocity, even if 80% of the code is written — see the Definition of Done.
A single sprint's velocity is too noisy (absences, holidays, surprises). A rolling average smooths that out.
Never commit to more than the average velocity, unless there's a known structural change to the team (new hire, planned absence).
Velocity climbing while the team's workload explodes is a warning sign, not a win.
Classic trap: comparing the velocity of two different teams makes no sense — every team calibrates its own points differently. Velocity is only useful for a team to compare itself against itself over time.
Artificially inflating velocity (over-pointing stories) makes it useless for planning.
Velocity is a property of the whole team, never a single person.
Two teams with the same velocity can have completely different definitions of a point.
It takes 3 to 5 sprints before an average velocity becomes genuinely useful.
See also Scrum.org: What is Velocity and the Agile Alliance's definition.
Points delivered per sprint calculated from your finished stories, no spreadsheet to maintain. Free.