Velocity is a measurement of how much work a team can get done in a sprint.
At the end of the sprint the team’s “Velocity” can be calculated by adding up the estimates (in our case story points) for those items that have reached ‘done’.
We can track Velocity over time from one sprint to the next to work out an average and this serves as a useful guide when thinking about work at a roadmap level and release planning. If we have a well-defined backlog and a stakeholder is pushing for a hard deadline that seems unreasonable based on the estimate, we could use this empirical data to negotiate the requirements or the due date depending on what is preferred.
It can also serve as a good guide on how much work we should commit to when planning a sprint. We could use the sprint planning sessions to look at backlog items and based on their business value/ priority and story points it should become easier to pull work in to a sprint which is both realistic to what we can achieve and delivers the highest return on investment development wise.
Velocity also helps to monitor progress of a current sprint. When we plan our work and commit to getting it done in a sprint we can calculate the total amount of story point we need to complete within the sprint. Say for example it is 100 for Team A. There are 10 days in a sprint, which means ideally to achieve the sprint goal we would need to be checking off about 10 points each day. Daily as part of the stand ups we would look at the amount of story points completed yesterday and plot them out on the burn down chart. There is a line for the ideal / forecast velocity and then we would plot the actual. I have attached a couple of examples with additional information.
