Scrum Team Velocity – Is it a Stick or a Carrot?

Velocity, the measure of total story points completed in a sprint, is often misunderstood, and used as a “stick” against teams rather than a “carrot”.

I was once asked about trying to prevent a dip in velocity during team member vacations. Today I saw a post in LinkedIn titled “Tips and Techniques for Maintaining Velocity during vacation times”.  The very question of how to keep velocity the same during vacations represents a gap in understanding of both why we use velocity and what velocity is measuring. Velocity is expected to dip when team capacity drops. Otherwise, we are falsely trying to use velocity as a prediction of what can be accomplished in a sprint. Where “management” stresses the need to have a steady velocity regardless of what is going on in a given sprint, it is like using a “stick” to motivate the team. It also encourages “gaming the system”, creating a false sense of security and velocity. We use delivery of quality software as our main measure of success. We use velocity to predict how much work we can commit to in order to become reliable, predictable, and consistent.

Most teams use points to estimate stories, the number of points completed is the teams velocity. The goal is to become predictable and consistent. Velocity is not normalized across teams, and cannot be compared across teams. Once you realize this fact, then it is easier to accept an explainable dip in velocity. Note: If you are following SAFe (Scaled Agile Framework) and trying to normalize points see http://www.scaledagileframework.com/iteration-planning/  In Safe, a 1-point story is normalize, but story points vary from there. A SAFe teams’ velocity should not be compared to any other.

Given a team has been together for at least five sprints, and story points are being used for relative sizing of stories in a consistent fashion, the team’s velocity will begin to stabilize. Good Retrospectives will provide insight into improvements activities that may help increase the team’s velocity a point or two each sprint.

With a stable velocity and team, we can predict what velocity can be achieved for any sprint. If Monday is a holiday, or if one team member is on vacation for the entire sprint, ScrumMasters can help guide the team to not over-commit. Thus supporting a sustainable pace, and exhibiting the true value of velocity as a measure.

Let’s take a look:

Team Wolf

Team Wolf has 6 members, and a velocity of 40 for a two week sprint. I calculate capacity (the number of hours available to work in a sprint) at 6 hours per person, per day. For Team Wolf, a 10 day sprint has 360 capacity hours.

One bank holiday during a sprint

Capacity is 324 hours, (6 * 6 * 9) resulting in a 10% lower number of hours in which to complete the sprint’s work. I would encourage the team to commit to approximately 10% less work and aim for a velocity of 36 points.

One member on vacation for the entire sprint

Capacity is 300 hours (5 * 6 * 10) resulting in a 17% lower number of hours for a sprint. I would encourage the team to commit to approximately 17% less velocity, or 33 points.

Velocity dips can happen anytime for a number of reasons. A planned dip is not something to beat a team up over. Achieving the teams’ committed velocity is an excellent carrot. Reward teams, and celebrate successes.

Teams that are using the Scrum framework to become more Agile usually use velocity as a metric to help them understand how much value can be accomplished in a given sprint—which also gives a good idea of what value the release can hold.  This metric is something each team strives to improve through continuous improvement of their processes and teamwork.  However, the meaning is not altogether taken at face value…

When you think of velocity, what do you think of?  Do you think about the higher the number, the better or equating velocity to the amount of work the team does?  Does your team strive for high velocity?  If so, why?

Teams use velocity for a multitude of reasons; few of which are actually valid.  These valid reasons usually include improving themselves, using it for planning purposes, and sometimes for proving their abilities as a team.

When you remove the valid reasons, there are many other reasons that velocity is used as a metric, and some of them are not so ‘friendly’ to the team, or to being Agile.  A few I have heard or seen include: measuring the team’s pace, using it to force the team to do more than they are really capable of, using it to mix up teams, having it prove that “Agile fails”, apply it as a way to show risk to the project, and, maybe the worst, using velocity as a way to push the team into a ‘death march’ to completion.  I have seen many teams that end up failing because someone, who may not understand the purpose of velocity, pushes the team over the edge and they “storm” over how they should be working.

When we look at velocity, it is indeed meant to measure the throughput of the team in a given sprint—how much the team completed during the sprint.  The original intent of this measurement is to assist in planning the amount of work that the team can accomplish in a sprint, and therefore how much scope can be accomplished in a given number of sprints, or a release.

By looking at the definition and the original intent, you can clearly see how the intent can be morphed or twisted into some other purposes, like those listed above as the ‘not-so-friendly’.  This is not unlike many large companies in their infancy of an Agile transformation—they are not sure what to do with this new metric and so they use it as they see fit, even if it’s not the purpose.  When this happens, it tends to cause riffs inside the teams and across teams.  The worst scenario is when organizations that do not have the proper training or coaching in Agile attempt to ‘read between the lines’ and begin to infer things about the team, such as how hard they are working or even whether they are working at all.

It is important to understand that numbers do not tell the whole story, but merely start the conversation.  The conversation is worthwhile so that the team, and the organization, can better recognize what is happening with the team and how they are attempting to become more Agile.

Another murky side to how some teams’ velocities are used is to compare team to team—as if a higher velocity by one team over another means there is a better team.  The idea that teams can be compared by simply comparing velocities is a bit absurd—there are so many reasons that one team’s velocity may be higher than another’s, which is more evidence that numbers do not tell the whole story.  When velocities are used to compare team against team, you find that it creates friction between teams.  As the relationship between teams is strained, the value that the teams produce begins to dwindle or be of less quality.

Velocity is one thing that a team should never compromise; their velocity is what helps to keep them on a more sustainable pace and helps prevent them from getting burned out.  The biggest thing that velocity gives a team is a way to keep from committing to more than they can realistically deliver.

After reading this, would you change how you measure your team’s, or teams’, velocity?  Does it change how you interact with other teams?  Feel free to comment on how you use, will change, or see velocity.