I hear the word “commitment” used in problematic and misleading ways all the time. This is true when I am teaching Professional Scrum classes and even when I am coaching good Scrum Masters.
It often sounds like one of these statements:
How do we know how much work to commit to?
How do we make sure we will finish all of the scope we committed to for this release?
What happens if we don’t meet our commitment date?
The problem is that the word commitment has been MISUNDERSTOOD in organizations to mean a guarantee or promise related to delivery. And that is NEVER what the word meant in the context of Scrum. The Scrum Guide wording was clarified several years ago to try to avoid this misinterpretation, but unfortunately it persists within Scrum Teams and the wider organization. (In fact, I wrote a blog post a few years back to clarify the Scrum Value of commitment.)
You might be thinking, Stephanie, I know this and my team and organization already know this.
Are you sure about that? Even if we talk about complexity and unpredictability, do you still see signs that people hear that word commitment as a really strong likelihood? Is it considered a bad thing to not meet a “delivery commitment” or even to just not get done all of the work that was originally planned in a Sprint?
Why is this misuse of the word “commitment” problematic?
Remember Scrum is a framework for navigating complexity and unpredictability. The moment we start thinking we can promise a specific scope or guarantee something will be ready by a certain date, we are no longer seeing our environment clearly.
And we are no longer embracing empiricism.
This will limit our ability to navigate the unknowns and changing conditions effectively because we will stop seeking greater transparency – to progress, to value, to quality, to customer needs, to the product environment. We will not want to find out our assumptions were wrong, so we can stop or pivot sooner. We will want to plan everything out in more detail, so we can “be sure” our estimates are “right” (note: all estimates are wrong).
And then we will put our heads down and power through pre-defined solutions, rather than seeking innovative solutions by collaborating frequently with users to validate we are solving the right problems and solving them effectively. Maybe we will even sacrifice quality “just this once” to meet that stakeholder expectation.
Essentially, we will not be having the right conversations early enough to respond effectively to change and new information. We fall into the trap of trying to predict, control, and plan perfectly. Even when a Scrum Team is “doing Scrum,” they may not maximize the benefits of business agility when they or those around them start to fall into this trap.
So how do we avoid falling into this trap?
We need to take back the word “commitment.”
There are two steps involved every person can take:
- Be careful in our language, only using the word “commitment” as intended.
-
Clarify when we sense the misunderstanding is present.
When we are talking about a forecasted date, budget, or amount of scope, use the word “forecast” or “best guess” – NOT the word “commitment.”
And if someone else uses the word “commitment” incorrectly, clarify what is really being said. You don’t need to blow an air horn, pull out your Scrum Police badge, and declare, “that is not the right use of the word commitment.” You can simply restate and clarify what the person is saying, using this opportunity to have better conversations about what really matters. And you may also have the opportunity to educate people on what commitment does mean.
Here are a few examples of helpful ways to reinforce the true meaning of commitment.
We commit to upholding quality standards, so we will not sacrifice quality just to meet a forecasted delivery date. And we will always be transparent about our progress, open and honest about uncertainty and risk, and clear about what we are learning as we seek towards our goals. Because we want our stakeholders to be able to make decisions based on the best available information.
We commit to staying focused on our Product Goal XYZ for the longer time horizon. We will inspect our progress towards this Product Goal every Sprint and adapt our Product Backlog based on what we have learned. And if we feel we are not making much progress towards our Product Goal each Sprint, we will have the tough conversations about why this is happening. Perhaps we need more focus and that means saying “not now” to other enhancement requests. Perhaps we will realize that our environment has shifted, and we need to change the Product Goal. Either way, this commitment guides us and helps us have better conversations.
Will you join me in committing to take back the word “commitment?”