How would you estimate how long will it take to have build something, an app or a website? It’s easy to do the estimates based on historical data – if you’ve done already something similar before a few times. However, if you are building something not done previously it’s relatively hard to do the estimates.
Software estimation is very hard because often developers work on unique features and functionality. Then there’s collaboration within the team and often code changes in one area influence other areas as well.
Velocity is used to do pretty accurate estimates. Before starting the sprint, you do the sprint-planning meeting. Let say you have 7 user stories in the sprint. You’re not asking the engineers how long each one will take. You ask the engineers how hard is each story in terms of story points. There are different scales for this but as an example – 1 is the easiest, 2 medium and 3 the hardest.
After each story has a number assigned to it by the dev team, all the points are added and now your sprint has the total story points per sprint. At the end of the sprint, you see how many story points developers were actually able to complete. Velocity equals the sum of story points of each story finished per sprint. Usually each sprint equals to 2 weeks period. So for example if the team were able to complete 2 hard 3point stories, 3 medium 2 point stories and 2 easy 1 point ones, the velocity will be 14 points.
To predict the team performance more accurately and do the estimates better you use average sprint velocity that is average of 3 or more last sprints. So now, you see how much work can be done over a particular period of time (2weeks) in terms of story points. Now if you have an story points estimate from the dev team and you have past average velocity you can pretty accurately predict what time will take to ship specific feature or functionality.