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: Emergence. The glossary has the following description:

Emergence: the process of the coming into existence of prominence of new facts or new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.

Want to take a guess how often this term is mentioned in the Scrum Guide? Only once. It’s mentioned in the Sprint Backlog chapter:

“The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.”

I personally think this is an interesting observation, because it doesn’t do justice to the importance of understanding Emergence in relation to Scrum. I might even say, because of Emergence we need a framework like Scrum. To analyse this idea a bit deeper, let us see what the breakdown does for understanding the description:

the process of the coming into existence

In Scrum context this is meant as a really big blanket description which can range from big new ideas for the product to technical insight to build the product to anything at all. This is fitting, because what it’s actually describing is part of the context of product development: we will see new things pop up during development. They will come into existence. What I always hope people using Scrum realize is that we are using Scrum as a framework out of necessity because of the inherent nature of product development being a fickle one with a continuous changes of requirements, technology and people. To cope with all these changes we need an approach to work that helps us steer on change where needed. Scrum has artifacts in place to ensure transparency on these changes that we have identified to be relevant for the product we are creating.

of prominence of new facts

It’s interesting to note how the description gives us three descriptions on what can be classified as Emergence in the Glossary. Prominence of new facts coming into existence means that before a moment in time the fact was already known, but not considered this amount of importance and after that moment in time it is. When relating to Scrum this sounds awfully familiar to re-ordering of Product Backlog items in the Product Backlog doesn’t it?

or new knowledge of a fact,

The second way emergence is otherwise described is quite simply: a new bit of understanding coming into existence. Although we just discussed changing prominence, this is certainly not the only attribute that can come into existence of known facts. Product development requires an approach where we use gained knowledge about a fact as late as possible before starting work in it, to ensure we have the most up-to-date and highest amount of knowledge possible about it. Hence why I advice against doing refinement on parts of the Product Backlog that are currently considered to be created somewhere in the far future. It’s also why during Sprint Planning we only plan for the current Sprint and no further than that. It’s even why Scrum allows re-planning for the Sprint Backlog when new knowledge emerges that has impact on the Development Team’s ability to reach their Sprint Goal. This is all emergence of new knowledge about known facts! Scrum fits this knowledge in the Product Backlog and the Sprint Backlog. This allows for transparency on all the changes the Scrum Team takes into account when creating their product.

or knowledge of a fact becoming visible unexpectedly.

It’s an interesting exercise to analyse why the third option is even mentioned. We have new knowledge emerging described in the previous part of the description already don’t we? If we take this part of the sentence literally it would mean the knowledge was already there before a certain period in time but invisible or less visible. After that moment it became visible without a way to predict that happening beforehand. Having described it like such I can’t shake away the feeling that the key word in here is “unexpectedly”. We cannot predict when certain knowledge of a fact will finally be gained. The ideal way to write a bit of code for your software might come in 2 months or in 5 minutes. The perfect idea for a feature might fall into our brains while in the shower. Because of this we need to approach our work in a way that copes with this uncertainty and ensure that we validate done work as early as possible. This will not decrease unpredictability, but it will force early decision making and small experiments. This will help decrease a big possible negative side-effect of unpredictability which is reworking continuously without ever finishing. How do we validate the work as early as possible in a Scrum context? The third artifact we haven’t mentioned before: The Increment. By validating done work with our stakeholders early and often, we can cope with unexpected changes, which is inevitable in product development.

Conclusion

If you do product development you get to deal with emergence. Whether it be through changing priorities, changing insights and knowledge or the changes happening unexpectedly. Scrum is an approach to be able to deal with those changes through creation of transparency on these and being react to them. As you hopefully realize by now, my statement at the beginning was not an exaggeration. Emergence is why we do Scrum.

Hopefully this article helped you understand a rather unfamiliar term to most people a bit better. I do recommend reading the other articles on the Scrum Glossary, they have a similar build-up and help you understand the term a bit better in Scrum context. I also share common minunderstandings in my articles about the Scrum Glossary. If you want to react or discuss, feel free to comment below and we’ll have a conversation about the subject.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*