Sprint Velocity is another term for the capacity a team has. It’s used to measure how many story points a development team can complete within a Sprint.
In order for a team to forecast how many story points they can complete within a future time frame, they need to have a record of story points already completed in the past.
Story points are numeric estimations for the level of effort a task (sometimes “ticket”) will take.
A Sprint is a short period of time that a team uses to focus on accomplishing bite-sized goals. Sprints are usually one to two weeks' long but the duration varies. It’s up to the team to decide what the duration is.
Sprint velocity is measured by dividing the number of story points the team has completed in a past time period by the number of sprints those points were completed in.
Here is the formula:
Sprint Velocity = Story Points (completed) / # of Sprints
A team’s sprint velocity allows them to forecast how many total story points on average they can complete from their backlog in an upcoming Sprint, after accounting for any known “drag”.
Drag is calculated by subtracting the known vacation, holiday (or other time developers won’t be coding) from the Sprint.
A key tenet of agile estimating and planning is that we estimate size but derive duration.
Individuals should be given every incentive possible to work as a team. If the team’s throughput is increased by my helping someone else, that’s what I should do. Team velocity matters; individual velocity doesn’t.
I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science, whatever the matter may be.