TL; DR: The Obsession with Commitment Matching Velocity
Despite decades-long efforts of the whole agile community—books, blogs, conferences, webinars, videos, meetups; you name it—we are still confronted in many supposedly agile organizations with output-metric driven reporting systems. At the heart of these reporting systems, stuck in the industrial age when the management believed it needed to protect the organization from slacking workers, there is typically a performance metric: velocity.
In the hands of an experienced team, velocity might be useful a team-internal metric. But, when combined with some managers’ wrong interpretation of commitment, it becomes a tool of oppression. So when did it all go so wrong?
👉 Join the poll and the lively discussion on velocity and commitment on Linked!
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
📈 Free: Download the Agile Metrics Survey 2021.
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 project’s progress and was looking for answers, starring at a bunch of Jira charts the Scrum Master prepared earlier. “How can we claim that we are practicing Scrum if the team is not sticking with the rules?”
Throughout most projects I have been working on, I could observe a management obsession with burn-down charts and other metrics, namely a team’s commitment. Consequently, the management interprets “commitment” as a list of work items the Scrum team promises to deliver during a Sprint. (Of course, the Developers only commit to achieving the Sprint Goal, not to a batch of specific work items.)
And as a consequence, the Developers’ forecast—in combination with their previous performance—is elevated to the most critical management indicator that “Agile” works: The team’s commitment is matching or outperforming its average velocity.
While I do see value in a projection regarding risk-mitigating—when can X probably be delivered to the customers—, the emphasis on its reporting value escapes me, though. It’s all playing safe again, corporate style when it should be about delivering excellent products that are valuable, usable, and feasible. It is no longer about maximizing the value of the team’s work in a complex environment with all its uncertainties. Instead, it is about disciplining the workforce to make accurate predictions. (Which isn’t possible in complex environments anyway.)
Cannot see the form?
Please click here
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,
- Different seniority levels,
- Working in unchartered territory,
- Working on legacy code, probably undocumented,
- Running into unexpected technical debt,
- Holiday & sick leave,
- Executive intervention,
- Public holidays,
- Pandemics, etc.
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 given the complexity of the underlying model.)
The Prime Purpose of Refinement, Sizing, and Estimation
And then, there is Product Backlog refinement and estimation. Many by-the-books Scrum practitioners tend to locate the value of these meetings in delivering an estimate on each Product Backlog item. However, in my experience, an estimate is just a side effect of the ensuing conversation. The refinement’s purpose is to create a shared understanding among the Scrum team members on the why, the what, and the how.
The result of this is plain wrong: In a distortion of reality, a volatile-by-nature figure of minor inherent value is compounded by a misinterpretation of the Scrum Guide to determine whether the team’s performance is on track and Agile is working.
Cooking The Agile Books
In such a scenario, the rational response of a Scrum 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. (Read more: The Hawthorne Effect.)
Does it sound waterfall-ish to you? It is, just with some Scrum sugar coating on top of it. (As I mentioned earlier, stripping Scrum off some “unnecessary” features, such as turning the Product Owner into a proxy or a scribe, creates a kind of 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 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.
Conclusion: Velocity And The Way Out Of This Dead-End
Instead of focusing on faux metrics, learn to appreciate actual KPIs that indicate value creation 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. The Evidence-Based Management Guide features plenty of examples of such metrics.
What is your take on “commitment matching velocity?” Is it probably the predominant metric in your organization? Please share with us in the comments.
Related Posts
Estimates Are Useful, Just Ditch the Numbers
Agile Failure Patterns In Organizations
Hiring: 54 Scrum Master Interview Questions To Avoid Agile Imposters
Cargo Cult Agile: The ‘State Of Agile’ Checklist For Your Organization
✋ Do Not Miss Out and Learn about Velocity, Sizing, and Estimates: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📅 Scrum Training Classes, Workshops, and Events
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
If you like to learn more about velocity and commitment, consider attending Stefan’s Professional Scrum Master classes.
This is an interesting and important topic that we have also been discussing in my company. Here my thoughts:
See the definition of “commitment” in the Macmillan dictionary (https://www.macmillandictionary.com/dictionary/british/commitment). In the Agile world, commitment is mostly understood as “a promise to do something” (see Macmillan’s point 2 definition), but it should really be seen as “enthusiasm for something and a determination to work hard at it” (Macmillan’s point 3). So yes, the team should commit – to doing the best they can to achieve the Sprint goal while keeping high quality their first priority. The newest Scrum Guide also talks about the “forecast [of] the functionality that will be developed during the Sprint” and of course of the value of commitment (to me very obviously as per Macmillan’s point 3 definition).
But yes, we should still be able to plan in advance. This is what I’ve tried with one of my teams: Instead of forcing the dev team to forecast what they’re capable of doing in the next 2 weeks, we moved to a kind of Kanban style work, where the ToDo column always has enough (prioritised) tickets and when the dev team is done with one, they take the next one into InDev. After doing this for a few “Sprints”, we looked at the velocity and it was pretty consistent. Now, months later, this team is the most consistent in the company in creating value and closing tickets. We also know the team’s velocity, so the PO can do roadmap planning without issues.
My observations: The team stopped worrying about creating velocity and instead just did their work in a flow. Before, the team would feel under pressure to achieve their promise which was often not possible due to the maintenance/support work the team needs to do, so they often planned a buffer – still, they felt like failures when they couldn’t meet their “promise”. So by changing things around, the bad feeling is gone and the team is properly committed to their work(!).
This is working so well, I’m planning to try it with another team also.
Another thing I notice a lot when teams are overcommiting in their Sprints: They don’t consider risk in their estimates. So they just consider the complexity, but not the uncertainty surrounding it. See Mike Cohn’s article on this topic: https://www.mountaingoatsoftware.com/blog/what-are-story-points
Interesting read.
Commitment-driven sprint planning involves hours, whereas velocity-driven sprint planning involves story points.
With commitment-driven sprint planning:
* if teams over-estimate hours, they come in well below typical velocity which raises questions.
* If teams underestimate hours, they come in well above typical velocity and will most likely have stories roll-over into the next sprint.
Plus, with tactics like “story triangulation” you end up with fairly consistent sizing. Thus I find it is not worthwhile for teams to “game” commitment-driven sprint planning.
As a scrum master I coach my teams to take pride in delivering what they – the team – commit to; no one is forcing you. So, if you trust your ability as a team, then choose the prioritised stories as a team and get it done.
So, it acts like a rallying point, a reason for the team to pull together and deliver, consistent quality sprint after sprint.
Furthermore, a commitment is not a guarantee; so no one will be fired or scolded for not hitting 100%; however, if the team typically complete 80-90% of committed stories then suddenly do 30% there will be several questions during the retro and we improve.
To be fair, I find delivery vs commitment a powerful measure that turns teams around; but it has been interesting reading alternative views here.
Absolutely, Manual. And you cannot blame them, as the demand for “scientific” predictability based on velocity is again just another form of mistrust.
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.
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.
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.
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.
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?
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.