Understanding Sprint Velocity: A Realistic Field Guide
In Scrum, velocity is the amount of work a team completes in a Sprint, measured in the units (story points, hours, or items) used to size Product Backlog Items. It is used to forecast how many Sprints will be needed to complete a set of backlog items, and to inform capacity planning for Sprint planning. Velocity is descriptive -- it describes what a team has done -- and should be used as a forecasting tool, not a performance target.
What Velocity Looks Like in Practice
A team that has completed four Sprints with velocities of 32, 38, 41, and 35 story points has an average velocity of approximately 36-37 story points. The range (32 to 41) is normal and expected -- Sprint-to-Sprint variation in velocity is the rule, not the exception. A team that consistently completes exactly the same velocity every Sprint is almost certainly sizing its backlog to match its target, not forecasting honestly. The normal causes of Sprint-to-Sprint velocity variation include: team member absences, unplanned support work or incidents, story point estimation variance, and Sprint goals that require different types of work than usual.
Scenario 1: Velocity Dropping Mid-Project
A Scrum team on a government systems modernisation project experienced a velocity drop from an average of 42 story points per Sprint to an average of 28 story points over two consecutive Sprints. The Scrum Master investigated and found two causes: (1) the team had been assigned additional support responsibilities for a legacy system during a peak service period, consuming approximately 30% of Sprint capacity; and (2) two of the team's five developers had been pulled into an architecture review for a different project. Both causes were temporary and resolvable. The Scrum Master escalated both to the Product Owner and management, the support responsibilities were redistributed, and velocity returned to the previous range within two Sprints.
Scenario 2: Velocity Used as a Performance Target
A development team was told by management that their velocity needed to increase by 20% to meet a project deadline. The team responded by inflating their story point estimates -- items that had previously been sized at 3 or 5 points were now sized at 5 or 8 points. Reported velocity increased, but actual productivity did not. The planning forecast became unreliable because the team's historical velocity was no longer comparable to the current velocity. The deadline was not met.
The lesson: velocity is a calibration tool for forecasting, not a performance metric. Pressuring teams to increase velocity produces gaming, not improvement. Genuine productivity improvements produce real velocity increases over time -- but those improvements come from removing impediments, improving team skills, and improving the quality of Product Backlog Items, not from setting velocity targets.
Scenario 3: Stable Velocity Enabling Reliable Forecasting
A mature Scrum team on a long-running infrastructure project had maintained a relatively stable velocity of 45-55 story points per Sprint over eight Sprints. Using this historical velocity, the Product Owner was able to forecast with reasonable confidence that the remaining Product Backlog (estimated at approximately 380 story points) would be completed in approximately seven to nine Sprints -- providing stakeholders with a reliable planning horizon for the project's completion.
XNM provides Scrum coaching and agile delivery advisory to public-sector organisations. Reach out to XNM's program & project delivery advisory team to discuss Scrum metrics and agile forecasting for your organisation.