Blog

When working with organizations or teams new to Agile, one observation we have noticed time and time again is the misunderstanding of velocity as an Agile metric. Many teams view velocity as something that denotes efficiency and can be controlled or improved if, “done right.” Other teams think velocity will provide exact timelines for delivery of a piece of code similar to how work is assigned. While velocity does provide insight into how much work can be completed during a given iteration, its true value lies in empowering teams to prioritize and right size their work to create an achievable roadmap with consistent value delivery to customers.

This article is a simplified overview for teams outside of software delivery to creatively apply velocity to their work. 

Velocity as an Agile Metric

Velocity, at its core, is the simple measurement of the rate at which a team consistently delivers business value to an organization’s customers. For most Agile teams, value delivery can be broken down into small units of functionality called user stories, which is a replacement for traditional team member role requirements. During each timeboxed sprint, teams will typically work to complete a number of “stories” from a product backlog that, once completed, will be released to the customer. 

To ensure the team is not committing to more work than they can realistically deliver during a timeboxed sprint (also called increments), the team will estimate each story, giving it a number of “points” that represent relative complexity (not Level of Effort) needed to complete that story. The total number of story points that can be included in a given sprint is determined by the team’s velocity. For newly formed teams, there are formulas and best practices that can be followed to set an “initial” velocity, but determining a team’s actual velocity is best calculated over a set period, typically 2-4 sprints. 

While calculating a raw velocity number is straightforward, and a quick activity, utilizing it as a metric to empower Agile teams and drive consistent value delivery is not a one-size-fits-all approach and takes dedication, trust, and time to build. To facilitate that unique growth, here is a list of nuances about velocity that consistently come up in retrospectives:

• A Team’s Metric – A team’s velocity is based on the relative sizing of the stories they are working on through the duration of the time-boxed period. As such, their calculated velocity is unique to their team and any direct comparisons of velocity across a program will be meaningless. Said bluntly: do not compare raw velocity numbers across teams; it’s comparing apples to oranges. If you are looking for a way to compare teams, consider looking at a team’s consistency of velocity against the success of meeting their commitments. A team with an inconsistent velocity may be on track to over- or underestimate their capacity to deliver on their commitments.
• Variance in Velocity – While some level of variance is anticipated, especially with immature teams, the drive should be for a consistent velocity iteration over iteration. Consistency in velocity enables teams to confidently size work and create product roadmaps that reliably release value to customers. An inconsistent velocity (increasing, decreasing, or waffling) is a sign that the team needs to reflect on their process and determine areas for improvement. This could be as simple as ensuring users’ scores are clear and simple to understand, or more complicated, such as eliminating external dependencies that can delay work.
• Team Visibility – Velocity is a team metric and should be a visible and active part of all planning meetings and especially the retrospective. This allows the team to be introspective and honest regarding their capacity and capabilities. It also provides the opportunity to identify whether anything has changed that impacts the team’s capacity to continue delivering against their historic velocity.
• Capacity / Capability – When teams have an established, consistent velocity, but are continuously under delivering against business objectives, it can mean that there are not enough people allocated to complete the work and/or existing people are not adequately trained against new technologies employed by the organization.

In a software setting, story points and velocity can be seen as a science, but in utilizing a pragmatic lens, these concepts can be effectively applied in all categories of work. A pragmatic approach to determining velocity creates healthy team dynamics, a collaborative culture, and more engaged employees. 

—

Do you have questions about how an Agile approach can help your organization meet its strategic goals? Our highly skilled consultants can help you turn a mountain-sized project into an attainable endeavor that will propel your organization in the year ahead. Click below to connect with our talented team!