What is Velocity?
To refresh our primary school physics basics, Velocity is a vector quantity that refers to “the rate at which an object changes its position”. If a person moves back and forth rapidly, always returning to starting position, it would result in a Zero Velocity. In other words velocity is not only the Speed at which someone moves, but it is also the direction that matters.
- What does velocity measure?
- To relate the concept of Physics velocity in software product development environment, Team Velocity is the run rate at which a development team delivers the product backlog and the way team accelerates (or decelerates) velocity during the product development.
- Velocity will gives us an idea about, the value delivered until now in terms of story points and teams ability to deliver certain number of story points within certain time frame
- In simple terms, Velocity is the amount of story points a development team capable of completing/completes in a Sprint.
- Usually, Mean Velocity is calculated by averaging the velocity of first few sprints, to understand the strike rate at which a team can complete the rest of the product backlog.
- Velocity is the number of story points completed by a team in iteration.
- Why is velocity important? Velocity is important due to several reasons listed below
- Velocity helps the team become more predictable.
- It also aids in predicting when all features from the backlog will be implemented.
- It can help the team to find out the next release date based on set of finite number of user stories.
- We can look at the team’s trend for an indication whether the team is getting slower or faster and act accordingly
- Velocity can be employed as a lagging indicator for understanding various root causes of several issues the team is facing like removing critical impediments, motivation that drives the team, training the team in areas of improvement, delete user stories, providing effective resources to the team, increasing product owner involvement with the team etc..
- For a new team, Velocity will increase for the first few teams and even out later. Velocity may not be forever fixed.
- Keeping the team composition and sprint duration constant, Velocity is a great metric to understand the team progress.
- How to measure velocity?
- The underlying principle of measuring velocity is to find out how much value a development team is delivering to the business. Velocity measures a team’s ability to turns user stories into new working software in a sprint.
- A new team getting into Scrum, initially adopt anyone of the 2 ways of sprint planning, Capacity Planning and Velocity Planning.
- The new team can plan for their total team capacity and pull certain number of stories into the sprint with all necessary buffers. After each sprint, velocity is measured. After 3 sprints, the average measured velocity can be used to predict the velocity for future, and there by completion date. The team may also take a guess of their velocity during the first sprint planning and adjust accordingly until the average velocity is discovered.
Scenario: Our team delivers 10 user stories. The sum of the story points equals 53. Our velocity is then 53. If, in the next iteration, our team delivers 25 story points, then our average velocity is 39, or (53 SP + 25 SP) divided by 2 iterations = 39 SP.
- Partially completed stories do not count towards Team Velocity. Velocity is all about finished, accepted and delivered user stories. Partially completed stories will not deliver working software to the customer, who creates a false sense of accuracy and they generate no business value to the customer.
- There are some advanced mathematical methods available to calculate velocity when team composition and number of team members are changing every sprint.
- Pitfalls when using velocity as a measurement
- Velocity is nothing until a history is established.
- Velocity is a backward looking lagging indicator and it will not show the good things coming in future.
- Velocity should not be used as a cane to punish the team.
- Do not compare Velocities of two teams to find out the better-performing team
- Bugs and maintenance work may also be considered part of velocity estimation.
- DO not measure Velocity to draw awkward conclusions about a team, project or Organizations