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 one of these terms in the Scrum Glossary: Scrum. The glossary has the following description:
Scrum: a framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artefacts, and rules, as defined in the Scrum GuideTM.
Finally we get to Scrum! So far in the series we have been describing what could be said to be elements of Scrum or commonly used terminology by people and organisations using Scrum. Now we’re getting to a description that is trying to convey to the reader what is actually Scrum itself. Let’s see what it clarifies for us, the reader:
a framework to support teams in complex product development.
Scrum is a framework, which differs from a methodology. A methodology is meant as more than just principles, as it also offers tools and practices, making it more prescriptive than a framework. A framework on the other hand offers a set of rules as a baseline structure in which you should fill in your own practices and tools as per the need that arises while using it. It’s the reason why Scrum can be described in only 17 pages (taking away the title page and table of contents) and why a methodology like Prince2 takes a book to fully explain as it contains best or even mandatory practices and tools to use and explain.
Scrum is a framework that supports at the team level. This is an often misunderstood concept, noticeably coming back in questions being asked about the framework. People miss the management and further organisation described in the Scrum Guide and ask for what Scrum says about these roles. However, Scrum works with just the roles as described in the guide in a single team and states these roles with their accountabilities are the only ones needed to perform complex product development. Anything else in existence would be to support those roles to perform their work, but are at best secondary support, and at worst impediments to the team. Hence, why it only describes the way that actual necessary roles perform their work.
Scrum is meant to be used in complex product development. This means that the occurrence of emerging insights because of changes is frequent enough to merit incorporating a response to these changes in the approach to work. Scrum is one of possible ways to approach complex product development by formally incorporating these change response moments in a set cadence.
Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules,
As described in the previous part of this blog Scrum is a framework that is team focused. The team that is being focused on by the framework is the entity referred to as Scrum Team in the Scrum Guide. This entity consists of three roles that hold their own accountability, namely the Product Owner, Scrum Master and Development Team roles. The events and artifacts as described in the Scrum Guide are also part of the framework. The rules however are a commonly skipped part of the description. It even states so in the Scrum Guide that the rules described bind these roles, events and artifacts. Deepdiving in the Scrum Guide shows that these rules are all over the document describing relations between the elements of Scrum. Often in the form of a “must” or “should” statement, but not always. As an example:
“Those performing the work and those inspecting the resulting increment must share a common definition of “Done”
The Scrum Guide explicitly states that a Definition of “Done” must exist when doing Scrum and not only that: Both Scrum Team and Stakeholders need to share common understanding on what it is. Rules are more woven through the accountabilities of each role and purpose of each event and artifact as we can see from this example.
as defined in the Scrum GuideTM.
The latest version of the Scrum Guide is the sole definition of the definition of what Scrum currently is. It’s good to understand that updates have been made in the past on the Scrum Guide which in some cases significantly changed possible interpretation and practice of the guide. For example, for the Sprint Review overtime the description has changed to add the purpose of the event and the role of Scrum Master is clarified since 2013 and since 2011 refinement has been a practice that is part of the framework instead of a tip.
It’s important to understand that a lot of practices that used to be required before 2011 according to the guide are still often misunderstood to be a mandatory part of the framework. The consequence of it being a framework is that it allows teams to use their own good practices and experiment to find out what works in their situation. This might seem bold to say but: If it’s not in the Scrum Guide, it’s not Scrum. It can be useful, sure, it can be used by nigh every Scrum Team in existence (Looking at your “Scrum Board”), definitely, but it’s not mandatory to do Scrum according to the guide. Don’t limit your experimentation by non-existent rules!
Scrum being a light-weight framework and it being used for complex product development are the two most commonly misinterpreted attributes it has. Scrum is described in the Scrum Guide and there is no additional theory hidden behind a training or book except for additional explanation, practice and experience. However, that doesn’t make it any easier to master. I hope this blogpost helps to understand the bigger picture and purpose of the framework a bit better from the perspective of the Scrum Glossary. Let me know in the comments if you have any additional questions!