Velocity’s Killing Your Transformation

Photo by CHUTTERSNAP on Unsplash

I might call it The Velocity Trap. It’s not that your velocity is too high or too low. That’s not what’s killing your transformation. It’s the fact you’re using velocity at all.

As new agile teams begin to learn agile, often through the lens of Scrum, they are taught this supposedly very important concept of velocity. And yet, if you ask a seasoned agile coach whether this concept is important or not, they will invariably tell you it is not. In fact, they may tell you it leads to — and even causes — some of the most common problems experienced in agile, even leading to failed agile transformations. Why is that?

To really understand this counter-intuitive and somewhat controversial concept, we need to walk through a sequence of logical steps.

• New teams often learn Scrum first. It remains, by far, the most popular agile toolkit around the world.
• Scrum uses a time-boxed Sprint, often in two week increments. Time-boxing, in theory, helps a team learn to think iteratively and write smaller stories that still deliver meaningful value that create the opportunity for feedback.
• The Sprint Review and Retrospective, when used as intended, help the team establish feedback loops with stakeholders and continuously improve their own process to deliver the right value to customers sooner.
• Sooner, not faster. So, in order to maintain the agile principle of a sustainable pace, Scrum has adopted* the concept of velocity and relative estimating to help the team only take on a Sprint’s worth of work at a time. (*while it’s not in the Scrum Guide, many practitioners seem to include this). The concept of velocity should be about capacity, not speed. But it often doesn’t get thought of that way, or used as such.
• Most teams don’t focus on establishing an outcome-focused Sprint Goal, and even when they do, often fail to meet their Sprint Goal and complete all work items because they often struggle in the art of slicing stories to be as small as they can be and still be valuable. Most retros include a discussion around breaking down stories better (which often continues, sprint after sprint).
• Velocity requires that the team estimate the effort of their stories and discuss their differences of opinion to be sure there is a shared understanding of the work before starting it. Developers need to have psychological safety with their teammates in order to both speak up and share honestly about their estimates and opinions.
• Most teams also struggle with knowing what to estimate and what not to estimate and frequently spend an hour or more each sprint on the function of estimating.

I think there are multiple possible conclusions to draw which all point to Velocity being a concept that is not something we should be encouraging teams to use. In fact, the practices a team uses to estimate Velocity are working against the team becoming more agile. Velocity is ruining agile and your transformation!

Working backwards, each of the logic steps above introduces its own challenges, misconceptions, and destructive practices that might be making your team less agile:

• Debates over what to estimate and time spent estimating. It can be argued that ANY time spent estimating is wasteful because you could have been learning or delivering more value. Some teams spend way more than one hour a week, which can represent multiple weeks of not working on value for customers each year, per team. Perhaps, instead, teams could have a conversation about how they might approach completing a piece of work. This has the benefit of exposing what folks are thinking, helps more junior folks learn and ask questions, and everyone might get an understanding about the risks, dependencies, and approaches to getting work done more explicitly, rather than being abstracted into a code of numeric values.
• Many developers tire of estimating and learn to game the system (planning poker, etc.) to go with the majority or relent quickly when they disagree so they can avoid conflict and spend less time estimating. Therefore, most estimates gravitate toward a “medium” size over time.
• Because the art of story writing and story slicing is hard, teams often don’t focus on this work and instead continue to write large stories rife with unknowns or not focused on value and worse, spend time estimating work that delivers no value to customers. There is often lip service and even guilt in retros, but rarely enough hard work to improve this skill over time. As a result, teams cannot predict how much work they can accomplish in two weeks, never mind on longer horizons.
• The false truth of using velocity to be sure the team is maintaining a sustainable pace breaks down when the team is unable to predict a sprint’s worth of work. So many teams do not receive the benefits of being able to deliver value reliably every two weeks which could be building trust with stakeholders and the rest of the organization nor do they enjoy the benefits of being able to allay fears that they will ever deliver work on time using this new way of working.
• When teams fail to write stories that deliver clear value, they also fail to collect meaningful feedback on value delivered which means they generally do not have great feedback loops to help guide their progress. A great feedback loop helps a team decide which work to do more of to satisfy customers and end users and which work to stop doing. So not having reliable, established feedback loops often leave teams floundering, hoping their work is useful, not building trust, and potentially working on items that are less valuable. This seems much more important than knowing if a piece of work is a 2 or a 3.
• What’s worse is that some leadership (who are also learning to lead and manage in new, unfamiliar, agile ways) tend to use this metric velocity to compare teams to each other. Velocity is not a measure of success or ability or even output on its own. It is only useful to one’s own team as a trend over time to understand what that team’s capacity is to do work. Velocity, as intended by those who advocate for it, helps estimate very quickly without having to count hours, meetings, the average number of disruptions, or minor hiccups in team member’s availability.

The problems above, if not solved, should make us question the usefulness of not just velocity but the utility of a two-week sprint and frankly, whether the constructs of Scrum are really the right place for a new team to start learning agile because there are so many challenges that often take a great deal of patience and time to click. Unfortunately, many organizations either do not have that degree of patience or are riddled with enough misconceptions of agile that they misjudge whether agile will work for them at all and give up on it too soon.

So, what should you do instead?

First an organization needs to set expectations properly about learning curves and there being a period of adjustment before teams can achieve the benefits of writing good stories, building short feedback loops and thinking iteratively in an agile way. Teams may find that Kanban affords them some comfort and space to learn these things while maintaining more specific metrics like cycle time that help them explain directly how good they’re getting at slicing stories and then delivering on those stories. And well, if you are committed to Scrum, one way you can mitigate some of the risks is to keep stakeholders more closely involved and share your successes and failures in learning agile as well as keeping them more involved in the work itself. And to help focus on the right type of learning and continuous improvement, maybe spend the time you used to use on estimating to work on story writing and story slicing and just count cards instead, making sure and validating that each card is actually valuable to our customers or end users.

(Thanks to my friend and fellow agile coach Jeff Kosciejew for reviewing and helping to edit and refine this post)

If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.

Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com

How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com

The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com

Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.