Agile Velocity: A Forecasting Tool, Not a Target
Agile velocity isn't about speed; it's a measure of a team's predictable output per iteration. It's used to forecast how much work can be done in future sprints and to estimate release dates. The footgun is treating it as a productivity KPI.
THE MENTAL MODEL: Think of velocity as a team's average throughput, not its top speed. It’s a historical measure of the amount of work a team can successfully complete and get to "Done" during a single iteration. Its primary purpose is to enable reliable forecasting and planning, providing a data-driven answer to "How much can we do?", not to measure or judge a team's productivity. It brings predictability to the inherently uncertain process of software development.
HOW IT WORKS: At the end of each sprint, the team adds up the story points for all user stories that meet their Definition of Done. Stories that are partially completed count as zero. After a few sprints, typically three or four, you can establish a baseline. For example, if a team completes 25, 30, and 28 points in their first three sprints, their average velocity is (25+30+28)/3 = 27.7. The team can then use this number, perhaps rounded to 28, as a guideline for how much work to pull into the next sprint planning session. This average should be continuously updated as the team completes more sprints.
WHEN TO USE IT: Velocity is an internal tool for the development team and its product owner. Use it for short-term and long-term planning. For short-term planning, it helps the team commit to a realistic amount of work for the upcoming sprint. For long-term forecasting, you can use it to project release dates. If the remaining backlog has 200 story points and the team's average velocity is 25, you can forecast that it will take approximately 8 more sprints to complete the work (200 / 25 = 8).
WHEN NOT TO USE IT: Never use velocity to compare the performance of different teams. Each team's story point scale is unique and relative to their own context, so comparing Team A's velocity of 20 to Team B's velocity of 40 is meaningless. Critically, do not use velocity as a management KPI or tie it to performance reviews. This creates perverse incentives, leading to story point inflation, quality compromises, and the destruction of the trust required for honest estimation. Once gamed, velocity loses all value as a forecasting tool.
ONE CANONICAL EXAMPLE: A team is starting Sprint 5. Their "Done" work from the previous four sprints was: Sprint 1 (22 points), Sprint 2 (28 points), Sprint 3 (25 points), and Sprint 4 (27 points). Their average velocity is (22+28+25+27)/4 = 25.5 points. During Sprint 5 planning, the Product Owner presents several high-priority stories totaling 35 points. Based on their historical velocity, the team explains that taking on all 35 points is risky and instead pulls in stories totaling 26 points, ensuring they can maintain a sustainable pace.
Read the original → agilealliance.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.