In Agile development, the best way to measure success is through team velocity. Have you ever underestimated how long it would take to build a feature or fix a bug? You get halfway through the sprint and a mild panic sets in as you remember the promises you made to your sales and customer success teams. Eventually, tasks begin to creep into future sprints and you’re none the wiser on how to better estimate engineering and product tasks in the future. You try approaching team members individually, attempting to pinpoint single performers who may be holding up the line. But ultimately, it becomes clear that your entire team has to maintain a shared ownership and momentum in order to build features quickly.
This is where team velocity comes in.
According to Scrum, Inc., team velocity is a “measure of the amount of work a team can tackle during a single sprint and is the key metric in scrum”. When you complete a sprint, you’ll total the points for all fully completed user stories and over time find the average number of points you complete per sprint.
Team Velocity = Total Story Points Completed Per Sprint / Number of Sprints
Defining Story Points within Team Velocity:
Agile development deals mainly with story point estimates. Story points involve relative estimation. People are mediocre at guessing how big something is in absolute terms, like hours or days – but are surprisingly good at sizing something up in relation to another thing. If you give a person two piles of beans, they probably won't be able to tell you how many beans are in each pile. However, they should be able to say one pile is about twice the size of the other pile.
That's the basis of story points. They're unitless scales of measurement which are sized in relation to other tasks. Unlike hours, which are based on consistent values, story points are based on arbitrary measurements. Their only purpose is to compare a task in relation to the sizes of your other tasks.
Agile projects prefer a point-based system for a couple reasons. You don't need to stress about how your “actuals” compare with your “estimates”. Relative estimates remind us that they're not meant to be used as a deadline.
For example, let's say in Sprint 1, a team completes a user story with 3 points, a story with 2 points, and a story with 5 points, totaling 10 points. They had originally committed to a 5 point story that they didn't complete, so it doesn't get included. In the second Sprint, the team completes 11 points. In the third Sprint, the team completes 9 points. At this point, the team's velocity is 10.
When calculating velocity, only include user stories that are complete. Incomplete Users Stories should be carried into the next sprint.
Team Velocity = Average Number of Story Points Delivered Per Sprint
Measuring your team velocity allows you to use previous estimates to predict how long upcoming work will take. Of course there will be dips when it comes to people being sick or on vacation, but you should be able to better understand the trends of your team’s collective productivity over time. With this information, you'll be able to make better predictions by looking at historical data and adjusting expectations moving forward. For example, if you notice that some Sprints you’re able to get 28 story points complete and others only 22, talk to your team to explore why this may be happening. Are you estimating inconsistently? Or are there other factors contributing to certain sprints being less productive than others?
How to Increase Team Velocity in an Agile Project:
Measuring your team velocity doesn’t mean much if you aren’t increasing that velocity. Ideally, when you increase your team velocity, you’re more quickly releasing features, shortening the time to value for your customers and increasing equity value for the company. Not sure where to start? Here are some ways you can continue to improve your team velocity:
Increase Visibility: To maintain collective team accountability, visibility is key. Wherever you are tracking production progress, make sure that everyone is able to access that information and encourage them to document what’s necessary in order to keep velocity at top speed.
High-Impact Daily Scrum Meetings: Daily meetings can often feel like a drag, creating major mental fatigue for your team. Make sure that you’re entering into these meetings with high-energy and commitment to keeping them direct and productive.
Don’t Skip The Retrospective: When a sprint ends, it’s easy to want to move on to the next thing immediately. However, without a retrospective, there is a higher chance of poor practices enduring, which will continue to slow down how fast your team can move forward. This is another opportunity for your team to share the responsibility and maintain an open line of communication.
Focus on System Bottlenecks Over Individuals: Improving a person’s individual performance is one way of tackling inefficiencies, but in many instances, it’s likely a case of a workflow or communication issue. If you’re frustrated and don’t know why features aren’t completed on time, take a beat and talk to your team about where the system may be failing them. This avoids any finger pointing and encourages honest feedback. (See #3 if you’re struggling to find the time to explore.)
Track Team Velocity with ZenHubNo one has time to calculate story points and measure velocity manually. That’s why we’ve made it simple with our Velocity Charts. Quickly see your team's historical speed of work. They provide a simple, at-a-glance picture of your velocity, as measured by the total number of story points closed in recent [Milestones](https://www.zenhub.com/blog/what-is-a-milestone-in-agile-project-management/). With these charts, you can see exactly how much value your team can ship each sprint. And since they're built using live GitHub data, you'll know they're always accurate.
Learn more about ZenHub’s Velocity Charts here.