Velocity

Velocity is how much work a team gets done per sprint, typically counted in completed story points. If a team finishes 18, 22, and 20 points across three sprints, its velocity is roughly 20. That average becomes a planning tool: it tells the team how much to pull into the next sprint without overcommitting.

What velocity is good for

Used correctly, velocity answers one question: given how much we've actually finished recently, how much should we commit to next? It turns wishful planning ("we'll do all of it!") into evidence-based planning ("we reliably finish ~20 points, so let's plan for 20"). Over time it also surfaces trends — a steadily falling velocity is a signal worth investigating.

How velocity gets misused

Velocity becomes toxic the moment it's treated as a productivity score or compared between teams. Because points are relative and team-specific, "Team A does 40, Team B does 20" means nothing. Worse, when velocity becomes a target, teams inflate their estimates and the number stops meaning anything — a textbook case of Goodhart's Law.

Why small teams shouldn't track it

For a solo developer or a team of three, velocity is self-surveillance with no payoff. There's no stakeholder needing a forecast and no capacity-planning problem to solve. The honest signal at small scale is simpler: are you shipping things, and is your cycle time reasonable?

How GritShip handles this

GritShip deliberately omits velocity charts and sprint analytics. It targets continuous-flow teams who measure progress by what's shipping, not by points-per-iteration. Teams that need formal velocity tracking are better served by sprint-oriented tools like Linear or Jira.