Scrum: The Obsession with Commitment Matching Velocity

The Fine Line Between Risk Mitigation and Falling Back into Covering Your Butt

The team hasn’t met its commitments once. Not once.

The atmosphere was becoming thicker by the minute. The management was displeased with the progress of the project and was looking for answers, starring at a bunch of Jira charts, I prepared earlier. “How can we claim that we are working in Scrum mode, if the team is not sticking with the rules?”

Throughout the majority of projects I have been working on I could observe an obsession with burn-down charts and other Scrum metrics, mainly team commitments. And as a consequence, a side product of backlog grooming, estimation and sprint planning is elevated to the most important management indicator that “Agile” works: The team’s commitment is matching or outperforming its average velocity.

Scrum: The Obsession With Commitment Matching Velocity – Hands-on Agile by Age of Product

While I do see its value when it comes to risk mitigating—when can X probably be delivered to the customers—, the emphasis on its reporting value escapes me. It’s all playing safe again, corporate style, when it should be about delivering great software that is valuable, usable and feasible.

Why A Team’s Velocity Is Volatile Per Se

There are so many factors that make any team’s velocity volatile per se:

  • New team members being onboard,
  • Other team members leaving,
  • Seniority levels,
  • Working in unchartered territory,
  • Working on legacy code, probably undocumented,
  • Running into unexpected technical debt,
  • Holiday & sick leave,
  • Executive intervention,

— you get the idea. Actually, you would need to normalize a team’s performance each sprint to derive a value of at least some comparable value. (Which usually is not done.)

The Prime Purpose of Estimation and Grooming

And then there is grooming and estimation. Many of by-the-books Scrum practitioners tend to locate the value of these meetings in delivering an estimate on each user story. To my experience, that’s just a side effect of creating a shared understanding among the team members why they will be building a certain feature. (If you like to brush up your understanding of the Agile Manifesto, now would be a good time.)

In other words: A side figure is correlated to a volatile-by-nature figure of a minor inherent value to determine whether the team’s performance is on track and Agile is working.

Cooking The Agile Books

If that was case, the rational response of a team to this metrics driven “management style” would be to regularly under-commit and over-sell the effort at the same time. Which would leave sufficient buffer to handle the unexpected. It means de facto cooking the (agile) books to provide the middle management with a (perceived) feeling of being in control.

Does it sound waterfall-ish to you? It absolutely is, just with some Scrum sugar coating in top of it. (As I mentioned earlier, stripping Scrum off some unnecessary features—e.g. turning the product owner into a project manager—creates a viable Waterfall 2.0 framework.)

From my perspective, the obsession with “commitment matching velocity” is one of many reasons that lead to the “Peak Scrum” effect and contradicts a lot of what Agile stands for. It’s like introducing socialism through the backdoor: All plans are fulfilled and yet (probably) little or no value is created in the process.

Faux Metrics And The Way Out Of This Dead-End

Instead of focusing on faux metrics, learn to appreciate real KPI that indicate that value is being created for customers and the company. And there are plenty of those available, just look for something supporting the successful delivery of valuable, feasible and usable software.

What is your take on “commitment matching velocity”—is it that the predominant metric in your organization? Please share with us in the comments.

Related Posts

Agile Failure Patterns In Organizations

Hiring: 38 Scrum Master Interview Questions To Avoid Agile Imposters

Cargo Cult Agile: The ‘State Of Agile’ Checklist For Your Organization

Why Engineers Despise Agile

7 thoughts on “Scrum: The Obsession with Commitment Matching Velocity”

  1. Absolutely, Manual. And you cannot blame them, as the demand for “scientific” predictability based on velocity is again just another form of mistrust.

  2. Goodhart’s law applies: “When a measure becomes a target, it ceases to be a good measure.” Using velocity to measure the performance of a team will most likely result in the team gaming velocity. If you use estimation, velocity highly depends on it. So, the team will just sandbag their estimates and increase them over time.

  3. Good approach, Ted. I try to do the same, although sometimes, it is not working out as expected. I started not so long ago running additional team polls on other metrics to compensate for the bean counting velocity approach, based on simple Google forms. Questions cover, for example, perceived value delivered in the last sprint, level of technical debt, team happiness. The seem to ease the conversation with managers, too.

  4. Thank you for these thoughtful articles. They certainly trigger retrospective thought and most importantly (at least for me) look into the “why”.

    I do like them as long as I’m able to catch and correct the dysfunctional behaviors that can occur that are described by the earlier contributors. What I like about them the most is that it provides visibility to the Team and then acts as an opportunity to discuss with the PO in more detail as work is in progress both during the Sprint as well as the Release. In addition, no matter how much we invest in education and coaching, people are going to interpret through their filters. By having visual radiators I feel it provides the possibility to see the dysfunctional behaviors earlier vs. later and then the opportunity to help correct. Just because people have manager and C level titles does not mean their perfect and I want to error on the side of seeing those imperfections as early as possible (shorten that feedback loop) so that I can mitigate / stop them from permanently negatively impacting the Team.

  5. Hi Matt, I haven’t yet figured out a solution. I am experiencing the “weaponizing” of the charts by the management as well, and it is really damaging the communication.

  6. My organization began using burn down charts and I quickly realized they did not help us in any form. They are an information radiator…especially in an org fighting transformation to agility. They began to get used as a weapon by C level people in the org. I wanted the teams to see how they were doing from sprint to sprint so we’ve been doing them in retro-style…no management allowed. We are not able to keep up with the demands and timelines around projects as it stands. I’m sure someone reading this post has been there…what are some ways you found to improve situations like this?

  7. I don’t like burndowncharts – the main reason being that most people who see thim totally misinterpret them to their own ideas. Unless everybody who sees it knows how agile works, they shouldn’t be publicly available at all. I think burndowncharts should be first introduced to the unexperienced scrum teams only in a way, where they know that neither product management nor anybody else outside the scrum team can see it. This will prevent the idea of being measured against it, and optimizing for looking good – and instead stay what it is supposed to be, a feedback tool for the team itself. Only when a team is mature enough to know what is needed to finish each of the tickets in a way that the result is valuable, usable, feasible, they will be able to seriously estimate and commit to tasks for a sprint. And only then people should start even thinking about showing this chart to outsiders or to compare the chart with older ones. And comparing with other teams should never been done, every team is unique.

Leave a reply

Your email address will not be published. Required fields are marked *