The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about the one of these terms in the Scrum Glossary: Coherent/Coherence. The glossary has the following description:
Coherent/Coherence: The quality of the relationship between certain Product Backlog items which may make them worthy of consideration as a whole. See also: Sprint Goal.
So Coherent/Coherence has something to do with the Sprint Goal as the statement refers to it. It’s actually a vital part of being able to create effective Sprint Goals. Let’s break it down again. Since the descriptive part of this statement is a single sentence we can’t look at this on a per sentence break-down. However, there’s a lot in this singular sentence to discuss so I’m going to break it down even smaller with you:
The quality of the relationship between certain Product Backlog items
What are we considering quality here? When talking about coherence between Product Backlog items this can be in numerous ways. Examples could be: to be built in a similar subsystem or for a certain platform, a set of coherent features, a set of user scenarios for a single user archetype, etc. There is no single answer to what quality means here. However if I could put it into words I would say it’s the set of items with the least amount of explanation needed for them to be considered a set. As this would mean it would make sense for anyone to group these together.
Which may make them worthy of consideration as a whole. See also: Sprint Goal.
This part of the statement explains why we would want the quality of the relationship between the items to be high. We want to have a set that we can consider as a whole to give the Scrum Team a reason to do the Sprint. A primary focus the team defines in their Sprint Goal for the Sprint.
An antipattern I often see when I talk to Scrum Teams is that they do not use a Sprint Goal at all. We will go further into the purpose of a Sprint Goal in the article that’s about that term in the Glossary. The blame for this is often sought in the Development Team not thinking hard enough about commonalities. However, from my experience the primary reason for them not having a Sprint Goal lies in lack of Coherence in the ordering of the Product Backlog.
A Product Owner should be thinking about what assumptions he/she wants to validate this Sprint, for what primary purpose does he/she wants to even invest another Sprint of costs? What is the expected Return on Investment? By answering these questions Coherence comes in to play, because certain Product Backlog items will already exist, or come into existence that will fit as an approach to answers that can come out of these questions.
Coherence is needed in Scrum to create Sprint Goals. To do so we need to look at Product Backlog items not just from a risk, value and effort perspective, but also from a Coherence perspective. By doing this we enable a team to more easily think of an assumption to validate, an investment to make or purpose to follow for this Sprint. This is beneficial to the quality of their Sprint Goal. We will discuss the Sprint Goal as terminology in the Scrum Glossary in a later article.
I hope this helped you understand Coherence and its relation to Scrum a bit better. Any thoughts or experiences you want to share? Let me know in the comments. Until next time!