In its simplest form, Velocity = A measure of features or functionality delivered per Sprint. In other words, velocity is an average measure of how much work your team can get "Done" during a sprint (per your team's "Definition of Done"). Sprints are short in duration (30 days or less), so velocity can be established early in a project and refined over time.
Velocity is established based on past sprint performance. You can't choose your velocity. It is what it is. Oftentimes, teams encounter external pressure forcing them to increase their velocity in order to meet a deadline. These requests are unhealthy and should be steadfastly avoided. Facilitating these requests will lead to more of them. Additionally, attempts to force short-term velocity gains will likely lead to negative, long-term impacts or low team morale. Teams attempting to force short-term velocity gains will commonly find that they are skipping reviews, abandoning code and test standards, decreasing code coverage, testing carelessly, or reducing collaboration–all which will lead to waste, lower quality, undesirable products, and delays in delivery.
Velocity should be organic, not forced. Organic velocity is derived from a well-established Agile approach, good team practices, and strong leadership which efficiently and effectively produce high quality, valuable products. This will promote a healthy team environment that is sustainable for the long term.
Leverage Velocity for Backlog Grooming
Decomposing and ordering the Product Backlog is typically a very complex and important activity. The inputs to backlog grooming are seemingly endless, typically including business value, effort, risk, budgets, time constraints, cross-team dependencies, and much more. Understanding a team's velocity will allow the Product Owner to make decisions throughout the backlog grooming process that will help maximize value delivery within the confines of these fixed constraints and other changing factors.
For example, let's assume the following:
- A team is working towards a defined target release date
- One sprint remains
- Recent/Average Team Velocity has been 35pts/sprint
- More Valuable Feature A is estimated at a combined 60pts of work
- Less Valuable Feature B is estimated at a combined 30pts of work
The Product Owner can determine with confidence that Feature A (60pts) is too large, whereas Feature B (30pts) is most likely achievable within the remaining sprint (given their 35 pts/sprint velocity). From here, the Product Owner can make an informed decision on the order of these backlog items, based on which option will maximize value, given the delivery constraints: Partially-Completed Feature A, or Completed Feature B? Another option would be for the Product Owner to decompose and implement specific parts of Feature A and Feature B, given collaboration and agreement with the development team that the work remaining on the sub-features will fit within the team's velocity for the remaining sprint. There are various ways to tackle this scenario, but the takeaway remains the same: Knowing the team velocity will be a key component to successfully optimizing value when there are fixed constraints and other changing factors.
Leverage Velocity for Planning
Once velocity has been established, it can then be relied upon to improve the accuracy and reliability of both near-term and longer-term release planning. There are several factors you may want to consider when using velocity for planning:
- First time together? A brand new team will have no velocity. However, more than likely, your Stakeholders will require your team's estimated productivity. Talk to your team and see what they feel is reasonable but beware; too much time spent on guessing what a team's velocity might be is wasteful. Place more value in doing the work, continuously inspect, and adapt appropriately.
- How long has your team been together? A relatively new team will likely take a few sprints to determine their velocity. In contrast, maybe your team has been together for a long time. You may choose to only select the most recent sprints when using velocity for planning, or you may choose to use a weighted average.
- What about outliers? If the velocity of a team's previous sprints has been: 45, 50, 10, 50, 45, then the team may likely decide to drop the outlier (10) when determining the best velocity to use for forecasting and planning. The same would be true for outliners in the other direction as well–let's say 80. These sprints provide valuable information, but should probably not be used for calculating the most likely case or average velocity for future planning. With that said, if there is a pattern or consistent and identifiable cause for these outliner sprints, planning should certainly account for these (e.g. Post-Release weeks, Release Stabilization weeks, etc).
- Is the team available? Life happens. Team members will take vacation days, get sick, have a death in the family, spend time celebrating holidays, etc–resulting in sprints with lower velocities. Release Planning and Sprint planning should take these factors into consideration as much as possible.
- What's new? Learning curves WILL affect your productivity–learning new documentation tools, adding/losing team members, learning a new application, onboarding new team members, etc. Plan accordingly and expect sprint velocities to be lower for short term planning.
- What are your Most Likely, Best Case, and Worst Case scenarios? One useful approach to planning is to calculate the team's Most Likely velocity using a median subset of sprint velocities within the planning range. From there, teams can use +/- percentage factors to calculate Best Case and Worst Case velocities for planning (e.g. +/- 10%); or they can use an average of actual velocities from a subset of sprints (highest and lowest) within the planning range. When aligned with a calendar, it will provide a general range of expectations for communication and planning purposes with Stakeholders.
While velocity is an extremely useful measurement, do not allow it to distract the team. It should never be the focus! Keep the team focused on doing actual development work and creating value. Have your Scrum Master promote organic, sustainable velocity, leverage your velocity, and keep your team healthy long-term.