I was once asked during an interview to define velocity. After a moment of contemplation, I answered that velocity is the amount of work that a team can produce in one sprint. According to Silberbauer and Coyne (2015) of Agile for Dummies
, "The total number of completed story points is the team’s velocity, or work output, for that iteration" (p. 17). These are perfectly reasonable mainstream definitions and are typical of what is regularly taught by Agile professionals.
Recently, I have come to understand that the classical definition of velocity inadequately defines that value in more dynamic and complex environments. For me, this revelation came to light about five sprints into a new Agile coaching situation. The team was fairly new to Scrum practices yet eager to learn, and the development team manager was a staunch Agile/Scrum advocate. The first three sprints after my involvement had progressed well, with the trend line moving in the right direction.
Things began to change as we transitioned into the fourth sprint, as the executives, and ultimately the product owner, began to exert increasing pressure to meet unrealistic and seemingly arbitrary (from the team’s perspective) deadlines. Team members, eager to please the higher-ups, happily took on many items during the sprint and worked long 18-hour days (sometimes longer), weekends, and evenings to meet the product owner’s goals. As an experienced ScrumMaster, I was very uncomfortable with the process and expressed my concerns. Being new to the team and having to choose my battles, I decided to let things play out, hoping for a team growth experience.
Initially, the sprint review seemed to prove me wrong. The team had achieved stellar velocity, more than double their historical value — 82 versus 30 story points (see Figure 1). The celebration and accolades were short-lived, thankfully for me. The fruits of the sprint were hastily released to production and presented to the customer. Within a two-day period, the QC team documented more than 200 bugs, damaging much of the goodwill we had earned with the customer up to that point.
Figure 1. Team Velocity
It was clear to the entire team that the approach we had taken was a mistake and that we had far exceeded our capacity. On paper, everything looked wonderful, but in reality, we had a disastrous launch and spent weeks picking up the pieces. Several weeks later, I was in a Certified Scrum Product Owner®
training class led by a respected Certified Scrum Trainer®
/Certified Enterprise Coach, when the topic of velocity came up. The group agreed initially on the classical definition of velocity, and I explained what I had experienced. The coach acknowledged my point and (to his credit) qualified the definition of velocity to be the amount of quality
software that can be produced by a team in an iteration. This has now become my de facto definition of velocity, and I now refer to exceeding this definition as terminal velocity
Silberbauer, A. and Coyne, B. Agile for Dummies.
Second ed. Hoboken, NJ: John Wiley & Sons, Inc., 2015.