Calculate the velocity for an Agile team by adding together all of the estimates for the completed User Stories in a Sprint. For example, if the team is using Story Points to estimate and complete five User Stories with estimates of 5, 2, 2, 3, and 1 respectively, then their velocity is 5 + 3 + 2 + 2 + 1 = 13.
If our team is estimating T-shirt sizes, it's not possible to say your velocity is 1L + 1M + 2S + 1XS, as this isn't easy to translate from Sprint to Sprint. Instead, assign numbers to each t-shirt size, for example, XS=1, S=2, M=3, L=5, and XL=8. Apply this method to any sizing system that doesn't use numbers.
Velocity is a metric that is used by the team for forecasting. For instance, during Sprint Planning we use it to gauge how many User Stories we think we can compete with in the upcoming Sprint.
We can use velocity in one of two ways. The first is by averaging the velocity from recent Sprints. If we take the last five Sprints it would look like this: (15 + 14 +20 + 12 + 16) / 5 = 15. The second uses the velocity from the last Sprint; an approach referred to as yesterday's weather.
From Sprint to Sprint, update the board so everyone can see the current value; here we're using the velocity from the last Sprint:
We track the trend over time using a velocity chart; this will look something like the following diagram:
The two vertical bars per iteration represent the work that the team predicted it could complete in Sprint Planning (Forecast) and the work the team completed during the Sprint (Completed).
Sometimes work "forecast" is higher than work "done," meaning the Sprint didn't go as well as the team predicted. Sometimes forecast is the same as done, meaning it did go as expected. Sometimes done is higher than forecast because the team completed all items on the Sprint Backlog and had time to pull in additional User Stories from the Product Backlog into the Sprint.
Velocity will fluctuate from time to time; causes include team members being on leave, or sick, or changing the iteration length. For example, if you have five team members and one is away for the next Sprint, in theory your velocity will drop by 20%. Team leave is one factor to take into consideration when Sprint Planning.
If a team feels the change in velocity is significant and worth discussing, they can use the Sprint Retrospective as an opportunity to understand why and see if the root cause is anything that they can fix.
Also, remember that velocity is just one aspect of our forecasting system. Another method teams often use during Sprint Planning is to break down User Stories into tasks. Some teams allocate hours to tasks and then add up the hours on all tasks at the end of Sprint Planning. They use the total hours to assess if their forecast for the User Stories in the Sprint Backlog is more or less right. Another aspect of forecasting is gut feeling, especially useful when working on small chunks of work which have an air of familiarity.
From an observer's perspective, velocity tells us the team's engine is working, but it doesn't tell us if what the team is working on is delivering value. The only way to measure value is through the software that we deliver meeting our user's needs.