Velocity measures “How much of the stuff we said we were going to do.. did we do?”.
Velocity is a team concept and should be internally consistent. These are not expected to be comparable across teams (because of how teams estimate differently).
We calculate velocity based on what we set out to do in a given sprint. When we get to the end of the sprint, we calculate how many planned points we completed (to the full Definition of Done). We do not include bugs (even if you plan to do them at sprint start) or unplanned work. Your actual velocity is the average of planned work completion over the past 3 sprints. This should inform how much work you take on (aka “commit to”) in the coming sprint.
Example:
The development team at MadeUp Co. began their sprint with a well-planned set of stories totaling 15 points, confident they could deliver quality work within their two-week timeframe. Three days in, however, the sales team burst into their stand-up meeting with news that a major client threatened to cancel their contract unless an urgent security patch was implemented immediately. Despite the product owner’s hesitation, the team pivoted to address this critical issue, which required deep investigation into their authentication system and coordination with the client’s IT department. By the sprint’s end, they had successfully delivered the security patch and just 3 points of their original commitment. During the retrospective, rather than feeling defeated, they celebrated their agility and discussed how to better accommodate similar situations in the future while setting more realistic expectations with stakeholders about the impact of mid-sprint changes.
This team at MadeUp Co achieved a velocity of 3. While this number was low, the team (and the sales folks) viewed this as success. This 3 combines with the 15 from the previous sprint and the 16 from the one before to give them a new target velocity of 11 points.