The words "commit" and "commitment" feature prominently in the 2020 Scrum Guide, and it's not just about the artifacts.
"The Scrum Team commits to achieving its goals and to supporting each other... when the Scrum Team and the people they work with embody these values, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust."
The Scrum Values contribute to people trusting and supporting each other. Let's trust people, give trust, respect, and not expect people to need to earn it. And let's continually improve together.
With the addition & clarification of accountabilities of the Scrum Team, the Product Owner, and the Scrum Master, avoiding "the five dysfunctions of a team," from Patrick Lencioni's famous book, is better accommodated by the 2020 Scrum guide. For example:
- trust each other,
- be open as a Scrum Team, do not avoid necessary conflict - for the good of the Scrum Team,
- having the courage to talk about the elephant(s) in the room,
- the new explicit commitments below,
- holding each other to account, and
- attention to results.
What is commitment?
commitment
/kəˈmɪtm(ə)nt/
noun
- the state or quality of being dedicated to a cause, activity, etc., e.g., "the company's commitment to quality."
- an engagement or obligation that restricts freedom of action, e.g., "with so many business commitments time for recreation was limited"
courtesy of Google and Oxford Languages
I subscribe to the former rather than the latter. Commitment in a Scrum context is about striving, genuinely doing our best, really doing our best. Let's not confuse this with not trying hard enough.
Addition of commitments to the artifacts
The 2020 Scrum Guide added commitments:
- to the Product Backlog artifact- the Product Goal
- to the Sprint Backlog artifact - the Sprint Goal, and
- to the Increment artifact - the Definition of Done.
"Artifacts that have low transparency can lead to decisions that diminish value and increase risk. Transparency enables inspection. Inspection without transparency is misleading and wasteful. "
The artifacts' commitments improve the artifacts' transparency, which helps inspection, which helps adaptation, which helps empiricism. Empiricism is deciding what to do next based on what we learn, informed by data, and feedback. The artifacts' commitments also improve focus.
So what's new or updated in the 2020 Scrum Guide concerning the artifacts?
Product Goal
The Product Owner ensures the Scrum Team has a Product Goal.
"The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next."
"Start with Why," as Simon Sinek's book title goes...
As JJ Sutherland said in his public chat with Patricia Kong and Dave West on 18th November 2020, "if senior leaders don't prioritize (or have 5+ top priorities), the most junior person gets to decide what's next" (paraphrased).
Picking one tangible, measurable, and succinct Product Goal provides real guidance on what's most potentially valuable.
Not every Product Backlog Item in the Product Backlog needs to contribute to the Product Goal. The Scrum Team should only focus on one Product Goal at a time. The 2020 Scrum Guide says that the rest of the Product Backlog emerges from the Product Goal. As there is no "parking lot" for the Product Backlog, in my opinion, it's not inconceivable that the Product Backlog wouldn't have vague longer-term Product Backlog items for a subsequent Product Goal(s).
That said, when dealing with complexity, fortune-telling is a fool's errand. So sticking to one Product Goal at a time is probably for the better, and it is required. The Product Goal acts like the North Star for a longer-term horizon than one Sprint. If co-designed by the Scrum Team, the Product Goal will inspire the Scrum Team, "lighting a fire inside people." (Dr. Lance Secretan).
I initially thought "Product Goal" was just new wording for the (product) vision; the 2017 version of the Scrum Guide mentioned the word "vision."
Before the term "Product Goal" was introduced, I talked about the vision or "direction of travel" as a set of objectives in three-time horizons:
- 3-6 month target condition (doable) - like SpaceX doing two autonomous docks and one manual dock with the international space station
- 1-3 year challenge (a stretch) - like SpaceX landing on the moon - see https://www.spacex.com/updates/nasa-selects-lunar-optimized-starship/
- 5+ years almost impossible perfection vision - like SpaceX doing sub-orbital flights as regular as air travel for commercial passengers - see https://youtu.be/zqE-ultsWt0
I find it useful to use multiple time horizons like this, as some people think very long term, some are looking at the next year or so, and some are looking at the next quarter. A Product Goal could be any of these time horizons or a different one—context matters. The Product Goal is a target, and the Scrum Team strives to attain it. The most appropriate event to review the Product Goal is the Sprint Review, as that's the event that stakeholders attend. Product Backlog Refinement is an excellent (and more informal) opportunity to review the Product Goal. But, the Product Goal could be reviewed at any time. And the Product Owner could abandon it. The Scrum Team owns the Product Goal commitment.
Sprint Goal
A discussion about the potential Sprint Goal happens during Sprint Planning "Topic One: Why is this Sprint valuable?" The Scrum Team must finalize the Sprint Goal before the end of Sprint Planning. It should be tangible, measurable, and concise, but most importantly, it should explain "the why." The Sprint Goal resides in the Sprint Backlog, alongside the selected Product Backlog Items and the plan to deliver the Sprint Goal. Sprint Goals should help the Scrum Team to navigate towards the Product Goal.
Not every Product Backlog Item in the Sprint Backlog needs to contribute to the Sprint Goal. The Sprint Goal acts like a North Star for the Sprint. It counteracts the possibility of whack-a-mole style delivery. The Daily Scrum is the most appropriate event to review progress towards the Sprint Goal. The Sprint Goal could get canceled if it becomes obsolete.
"Only the Product Owner has the authority to cancel the Sprint."
As well as improving focus, the Sprint Goal unleashes the Scrum Team's creativity to figure out how to achieve the desired outcomes. The commitment around the Sprint Goal is having one to improve transparency & focus and deliver potential value. "Finish all items" would be missing the point as it wouldn't unleash the Scrum Team's creativity.
I had examples in an FMCG where the Scrum Team figured out an easier way to attain the Sprint Goal; if they had committed to the Sprint Backlog, it would have been a missed opportunity.
"During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality does not decrease;
- The Product Backlog is refined as needed; and,
- Scope may be clarified and renegotiated with the Product Owner as more is learned."
Focus is at the forefront. The Scrum Team self-manages to find its way of establishing if the Sprint Goal is at risk.
The developers own the Sprint Goal commitment.
Increment and the Product Goal
"An Increment is a concrete stepping stone toward the Product Goal."
The increment must be done, thoroughly verified, and usable. The increment should hold the potential for value.
Definition of Done
"An Increment is a concrete stepping stone toward the Product Goal...
Work cannot be considered part of an Increment unless it meets the Definition of Done."
The Definition is essentially a checklist for "how we do things around here." The Definition of Done considers product quality attributes and technical quality attributes. Hence, it sets the quality expectation; it helps the Scrum Team compare apples with apples, improving transparency. The Developers commit to the Definition of Done, whether it comes from or is based on the organization's standard Definition of Done, a team of teams for the product, or the Scrum Team. Sprint Planning Topic Two guidance is clear about the relevance of the Definition of Done.
"The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done."
The hardness of the commitments
The Product Goal is aspirational as we navigate complexity over a longer time horizon. The Sprint Goal is a more demanding commitment; that commitment is still inferior to the commitment to the Definition of Done. The commitments related to the Product Goal and Sprint Goal are about focus rather than a guarantee/promise. Quality is not a victim in Scrum. If there are challenges with attaining commitments, the Scrum Team needs to have a timely discussion.
Conclusion
In Scrum, we get to change our minds, and quality does not suffer.
I started as a programmer, and I practiced Scrum since the mid-2000s. I have worked in agility for non-software for the past three years, working with people in legal, people operations, engineering, natural sciences, and marketing & sales. I am encouraged by the flexibility of the 2020 Scrum Guide. I would encourage all teams to consider the adoption of Scrum. Just make sure you're getting feedback from customers & end-users.
Opinion
The words "goal" or "vision' are misnomers when dealing with complexity. Revolving / evolving from the present in a "direction of travel" would be more appropriate. There should only be one direction of travel at a time. If there is more than one direction of travel, they have to be consistent with each other.
Context is king. All things being equal, I prefer a usable done increment that offers transparency over an attained Sprint/Product Goal that includes unsustainable short cuts.
If using OKRs, I recommend you use aspirational OKRs to reduce the likelihood that quality suffers. The word "committed" in "committed OKRs" has an obligatory aspect. So, tread carefully with OKRs and complexity.
Metaphorically speaking, Scrum is a heat-seeking missile for potential value when combined with complementary approaches from Lean and Product Management. It's more than ok to reflect on analytics and experiments' results, but the Scrum Team strives for a done & usable increment every Sprint. It's more than ok to review research and low-cost experiments at/before the Sprint Review, alongside the increment. The Scrum Team harvests real value when customers & end-users provide feedback or change behavior.