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.

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.

The fourth edition of 2018 is now spanning seven topical categories, just a few of these questions will give you more than enough material for an engaging 60-minute conversation!

The download is available as a PDF delivered to your email address. Please note that downloading this content will also subscribe you to our popular, professionally-curated weekly 'Food for Agile Thought' newsletter if you aren't already subscribed. You may, of course, unsubscribe at any time.

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.

Receive a professionally curated summary of the best posts on the Internet about Agile, Lean Methodologies, and Product Management — delivered to your inbox every Sunday.

We've received your request — you're almost subscribed! Please check your email to confirm your subscription. We look forward to sharing the best Agile and Product news and insights with you! NOTE: If you do not receive the confirmation email within about 10 seconds, please also check the spam folder. Thank you!

There was an error submitting your subscription. Please try again.

Name

Email address

We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.

Published by

Stefan Wolpers

Stefan — based in Berlin, Germany — has been working for 12+ years as agile coach, ScrumMaster and Product Owner. He is an XSCALE Alliance XBA Coach (XBAC) as well as a member of Scrum Alliance (CSP, CSPO, CSM). He is also a certified LeSS practitioner (CLP). He has developed B2C as well as B2B software, mainly for startups, including a former Google subsidiary.

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

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.

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.

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.

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.