Velocity: It’s Strictly a Team Measure

August 14, 2013

But just what is velocity? It you equate velocity as a strictly a measure of speed that can be universally measured and compared, think again.

Speed measures how fast you are going, but velocity adds an extra dimension: direction. Therefore, velocity is a measure of how fast you are moving in a given direction. When it comes to agile (Scrum) teams, velocity is a measure of how fast a team is delivering value to the customer, following the direction set by the product backlog.

A few key factors that impact a team’s velocity:
  • The composition of the team and team dynamics.
  • The adaptive state of the product(s).
  • The practices (or lack of practices) employed by the team.
Team Composition and Team Dynamics
From an agile perspective, this relates to:
  • Staffing and whether the team is composed of individuals who have the skills required to complete the work identified by the product backlog. Agile teams are cross-functional teams that are responsible for delivering vertical slices of functionality, requiring diverse skills to contend with business logic, UX, data access, etc.
  • The willingness and ability for team members to develop and leverage “T-shaped” skills, where they are deep in one area but able to learn and contribute in other areas for the benefit of the team by interchanging traditional, functional roles. Scott Ambler calls these people Generalizing Specialists.
  • How collaborative members of the team are, where their mutual trust and respect enable them to work openly and collectively in ways that create that “2+2=5” dynamic.
Teams will obviously be in different places at different times, depending upon how much agile experience the team members have and how long that they have been working as a team.

The Adaptive State of the Product
The product(s) that the team is responsible for affect velocity. Some products have a long history of features being crammed in under deadlines and pressure that led to the creation of technical debt that is now impacting the ability to easily add new features.

As I noted in my last post: “To be adaptive, the product must be actively managed to keep technical debt at a minimum. If we don’t keep technical debt under control, features will take longer and longer to implement because the code base is becoming complex and unwieldy, with the likelihood that we will break other things as we adapt the product.” (Actually, I should have said “… as we continue to adapt the product.”)

Practices Employed by the Team
The first part of the agile equation is in how work finds its way to the team, which should be through the product backlog. In last week’s post I talked about how the product backlog is an enabler of responsiveness and adaptability.

From a team velocity standpoint, size and clarity are the paramount concerns: clarity on what the user wants and how they expect to benefit along with being small enough to implement in a Sprint (and we should be able to handle multiple user stories in one Sprint). Small sizes aid in making things understandable. And ideally the user story should be implemented without depending upon other stories as much as possible, since juggling dependencies creates risk and overhead.

As Bill Wake noted in INVEST in Good Stories, and SMART Tasks, we should INVEST in good user stories:

Moving on, we have a mix of key technical and Scrum practices that when combined allow us to coordinate what we are building and how we are building it, efficiently and effectively flowing value through the team:

This diagram uses some Visual AGILExicon® components by Kenneth Rubin and Innolution, LLC.

As you can see, there are five technical practices included with three Scrum practices.

Pair programming is the first. Pair programming (I like to use if for difficult, complex scenarios and not simple changes) eliminates the need for a separate design/code review later. We benefit by obtaining real-time feedback accomplished by developers interacting with one another.

Refactoring is included as a step in Test-Driven Development, which combines to give us automated unit tests – and the confidence that the changes we make to the product tomorrow aren’t breaking other things – along with keeping the code base understandable and maintainable. The speed at which we obtain feedback through these automated tests is the key benefit.

Continuous Integration provides us immediate feedback on changes that the entire team is making because we not only check in code frequently, we execute automated tests that inform us if there is an issue. We don’t wait for days or weeks to obtain feedback on code changes.

Validation – which routes out defects – is another step that should be supported by automated testing as much as possible. I’ve included it closer to the last step since we need to make sure we satisfy the Product Owner’s acceptance criteria along with the team’s definition of done before a product backlog item makes it into a Sprint Review. Product Owners should work with the team to accept or reject results as soon as the work items are completed, and not wait for the Sprint Review.

This brings us to the three Scrum inspect and adapt events depicted:
  • The Daily Standup (Scrum), which is all about team planning and coordinating for the day (and is not a status report), inclusive of identifying any impediments that must be cleared to keep the team productive.
  • The Sprint Review, which allows the stakeholders to review the product and request changes. Frequent review cycles used by Scrum allow us to catch those “now that I see it” issues early, before we add more code on top of functionality that should be changed.
  • The Sprint Retrospective, which allows the team to stop, reflect on what is working and what need to be removed, modified or added so that the team can improve on its timely delivery quality software.
When it comes to improving productivity, the “easy button” that can and should be attacked is the amount of work in process (WIP), as many organizations have too much work in flight and are overwhelming their people without realizing it. I have some additional thoughts on this in a post, The Benefits of Limits.

Once we have WIP under control, improving velocity is the next order of business since we’ve created the space to generate results without swamping the boat. However, improving velocity involves considering multiple, interrelated factors that takes time, effort, training and coaching along with some patience.

I sincerely hope that this post explains why velocity can’t be readily used to compare one team against another: There are too many variables involved. We need to evaluate team velocity in the context of their reality, which is definitely going to be different from any other team. I'm equally hopeful that I have given you some areas to examine when it comes to improving team velocity as well!


joseph said...

Velocity is a measure to help a team gauge themselves

November 10, 2014 at 11:36 PM
essay papers said...

Velocity is big factor in every industry. It's all about thinking from the eye of customers. If we want to give quality products to the customers than velocity of work has to be maintain.

January 27, 2015 at 4:02 PM
musical lessons said...

Forte schools offer a FREE trial musical lessons for classes and some offer Learn Piano, Guitar, Singing, Saxophone, Flute, Violin, Drums and More a Free Trial private lesson.

February 19, 2016 at 1:04 AM
John Alert said...

I have read your blog its very attractive and impressive. I like it your blog.

Dot Net Training in Chennai Dot Net Training in Chennai .Net Online Training .Net Online Training Dot Net Training in Chennai Dot Net Training in Chennai

Dot Net Online Training Dot Net Online Training LINQ Online Training LINQ Online Training ASP.NET Online Training ASP.NET Online Training

September 18, 2016 at 9:17 AM

Post a Comment