This post covers some Scrum vocabulary and processes that product teams use and how they align with the process experimenters’ use.
Let’s start with a basic question — why do experimenters need to understand Scrum?
Experimenters need to understand Scrum because a large number of organizations are using Agile & Scrum practices and you are likely at one such organization. Typically, such organizations are focused on adding value to their customers through their product. Running experiments provides insights all throughout the product lifecycle from discovery to exploration to validation. So, many product teams either have experimentation resources embedded or rely on a central team (Centre of Excellence) within the org to support their experiments.
Either way, experimenters work closely with product owners and other stakeholders who are already familiar with Scrum. So, it helps to speak the same language and have similar practices to inspire more confidence in the experimentation process and get buy-in from across the organization.
Scrum framework also provides a great blueprint for experimentation processes as we’ll dive into in a bit. Experimentation is equal parts art and science but a lot of it is driven by disciplined processes. The scrum framework is great for identifying potential gaps in those processes and making them more efficient.
What is Scrum?
My exploration started with reading this post on the SmoothApps blog which curated a treasure trove of other resources. The blog linked to the Scrum Guides which contains the definition of Scrum and explains each element of the framework in a straight-forward jargon-free manner. Many of the sections below have been picked up directly from the Scrum Guide since I didn’t want to lose the essence in translation.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. In a nutshell, Scrum requires a Scrum Master to foster an environment where:
* A Product Owner orders the work for a complex problem into a Product Backlog.
* The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
* The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
The Scrum Team is a cohesive unit of professionals — one Scrum Master, one Product Owner, and Developers — focused on one objective at a time, the Product Goal. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. So, rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation. And this is where experimenter’s can benefit from understanding Scrum.
How can experimenters align with Scrum?
Let’s examine each of these pillars.
The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts —
- Product Backlog
- Sprint Backlog
While it is hard to map experimentation artifacts 1:1 with those of Scrum, here are some thoughts:
The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides a set of events contained in a sprint.
Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts and are specifically designed to enable transparency.
Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Let’s look at each of these events and how they align with the experimentation process.
If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
In the context of experimentation, this means constantly trying to optimize the experimentation process. We should use every test as an opportunity to improve our processes — workflow, prioritization, sources of hypotheses, reduce bugs/ errors, etc.
The purpose behind this post was to demystify Scrum and point to similarities between its practices and the processes used in experimentation. My next post covers how product owners can use experimentation for refining product backlog. There is much more that can be explored on this topic — I’d love to hear your thoughts!
10 Steps To Strengthen Your Scrum Fundamentals
Here are some simple steps you can take from the comfort of wherever you might be to strengthen your Scrum…
Scrum Guide | Scrum Guides
This HTML version of the Scrum Guide is a direct port of the November 2020 version available as a PDF here. We…