Five Things You Must Understand about Agile Team Velocity

Agile team velocity is an often misunderstood concept that is prone to misapplication. This article sets the record straight.

As the Federal Government mandates the use of Agile software development practices in an ever-growing number of software development programs, the proper use of team velocity is becoming a significant point of confusion.  A misconception that seems to be gaining traction is the idea that the government can “buy” Agile software development services à la carte based on team velocities.  This contracting model would involve vendors offering prepackaged teams rated at some velocity.  Based on that velocity, the government could then pay for a certain amount of that team’s time to complete predefined tasks.  Agile teams would, in essence, be treated like plug-and-play units of Agile development capability.  This mentality is evidence of a fundamental misunderstanding of Agile, of what Agile teams require to be highly effective, and of the concept of Agile velocity itself.

What is Agile Team Velocity?

Agile team velocity is a heuristic measure of an Agile-Scrum development team’s throughput (not productivity).  It is the rate at which a team delivers fully completed, tested, and accepted user stories from the product backlog during one iteration/sprint.  Rather than simply adding up the number of completed stories at the end of a sprint, story points previously assigned to those user stories are added together.  At the start of every sprint, the team works with the product owner to clarify, decompose, and assign story points to user stories during sprint planning. Story points are heuristically-determined, numerical proxies assigned to user stories that represent the combination of perceived or estimated user story complexity, risk, uncertainty, and the level of effort required to complete the work.  This combination is often referred to as the “bigness” or “size” of a user story.  More complex user stories typically require more time and effort to complete thus, earning more story points than less complex stories.    Story points are the basis of a team’s velocity and velocity enables team estimates of the amount of capability (value) they can deliver, at a sustainable pace, within a sprint.

Σ Story Points of Completed User Stories During a Sprint = Velocity

Five Concepts that must be Understood about Agile Team Velocity:

1.  Story points are derived through relative sizing/estimation of user stories against each other by the development teams that will implement them.  They are not determined by a chief engineer, systems engineer, or some other senior authority as an estimation exercise prior to the establishment of development teams and the appointment of product owners.

2.  Team velocity is specific to the team.  Velocity cannot be used as a point of comparison between teams.  Team X is not necessary faster or able to achieve a higher throughput than Team Y because they earned a higher number of story points during a sprint.  The story points upon which team velocity is based are specific to the relative sizing performed by the team on their particular backlog of user stories.

3.  A team’s velocity is the end result of many factors, including:
  • Individual team member productivity across the team
  • Team cohesion, collaboration, and effectiveness
  • Team skill set and experience mix
  • Level of programmatic support (i.e., the factors that fall under the purview of program management)
  • Empowerment and level of engagement of product owners
  • The team’s familiarity with the business domain, technology mix, and enterprise architecture
  • The amount of automation leveraged in building, testing, and deploying code
Thus, the make up of the teams and the environment or ecosystem within which they operate determine velocity.  Team velocity is ultimately a proxy for the overall health of the software development program and organization.  When team velocity stagnates or drops, the search for potential causes must be systemic as opposed to a hunt for individual culpability.

4.  It is normal for team velocity to fluctuate.  What should concern us are large fluctuations or downward trends in velocity.  Changes in personnel, technology, organizational structure, etc. will affect development teams in different ways and to varying degrees.

5. Improving team velocity is not the goal!  Improving team capabilities, practices, tools, and programmatic support improves team velocity.  Focusing on improving velocity results in attempts to game the system rather than systemic improvement.

Bottom line:  Agile development teams are composed of people.  People are not machines calibrated to deliver a predetermined rate of output.  Teams need time and stability to gel into highly effective teams.  Helicoptering Agile teams, even experienced ones, in and out of tasks significantly degrades velocity except perhaps for the most mundane and menial of tasks (In which case, why employ Agile at all?).   Decades of reducing people to resources to allocate across Gantt charts has led many to also think of Agile teams as abstract productivity units. Agile requires much more of us.

Scaling Agile within the Federal Government Presentation at the Washington DC PMI Chapter

I want to thank the Washington DC PMI chapter for the opportunity to present the topic, “Scaling Agile within the Federal Government” last Wednesday, 27 September 2017.  A diverse group of program management professionals attended and shared valuable insights about their own experiences with Agile adoption within the Federal government.  You may download the presentation below.  You can read the chapter’s announcement of my presentation here.  The chapter hosts many interesting speaking events throughout the year, a number of which I will be attending.  I highly recommend participating as an attendee or speaker whether you hold a PMI certification or not.