What’s team’s velocity?
Team’s velocity is the speed the Scrum Team delivers a Minimum Viable Product (MVP). The MVP is a version of a product with just enough features that are to be used by first users. To determine how fast the team is working, we multiply story points by the number of Sprints. At the end of the Sprint, the Scrum Team look at the done completed requirements and add the story points together. To determine velocity, you need a couple of Sprints to have an average. Velocity isn’t a goal; it’s an extrapolation.
Why do we measure team’s velocity?
Velocity one of the most frequently measured metrics. Time is money, so the management of the organization wants to know when the product delivery is due. “Sprint”, the hearbeat of Scrum, as such relates itselft to speed (velocity). It’s pretty natural to measure Sprinting. As we’ve mentioned in the previous post, the effort that the team must put to deliver the Sprint requirements is measured by story points. Some might as well total the number of user stories to determine team’s velocity.
Velocity is a metric that we can do without
During the Sprint planning the Product Owner provides the Team with the product vision. Based on this data, developers select the Product Backlog Items from the Product Backlog. Afterwards, they give their estimates as to how much work will be necessary to complete these requirements. The Scrum Team sums up the story points and forecasts the product delivery. Team’s velocity is one of the metrics comprising the team’s efficiency. However, it’s not dead important, as it varies from team to team and from Sprint to Sprint. When the Sprint is called off (the Sprint goal is obsolete), we lose the average velocity from the previous Sprints. Most importantly, it’s necessary for the requirements to meet the DoD to be counted into as the average velocity.
Don’t forget it’s forecast, and not reality
The first thing that the Scrum Team must pay attention to during Sprint planning is they select the stories they think they’re able to complete in a given iteration (Sprint backlog). Then they count the points together. They can compare this data with the the number of story points from the previous Sprints. If there is a huge gap in value between the figures, then it should set the team thinking.
Let’s not focus only on velocity
Keeping with the projected velocity shouldn’t be the most important objective of the team. It’s main goal should be to bring value. Sometimes less means more. Scrum is more about quality than efficiency. Product Owner shouldn’t get the Team realize the exact number of story points it committed to complete. We’d focus only on numbers and not quality. There might also be a temptation to compare velocity between Scrum Teams. That’s why I keep thinking that this metric seems to be overused and overestimated.
