The to-do list. It serves as an optimistic guide for one’s day or week, whether hanging on the side of a refrigerator, typed into a smart phone app, or scrawled on a scrap of paper and stuck in some unavoidable spot. My favorite eye-catching place for a sticky note is the back of my smart phone. I know. I’m a Luddite that way.
Rarely does a to-do list act like a set of critical instructions we need to complete in lock-step entirety; things get added or deleted on the fly. That’s just the way life goes, like when you use a list to try to navigate past grocery store freezers of ice cream toward misted bins of salad greens. Often, an unplanned pint of Ben & Jerry’s will be nestled next to a bunch of lettuce come check-out time.
From a ScrumMaster’s perspective, our personal to-do lists share a lot in common with a team’s sprint backlog: Both are carefully selected from a master backlog of to-do items. However, there is one major difference between the two. A grocery list is viewed as being inherently flexible, whereas a Scrum’s sprint backlog is not.
As The Scrum Guide
co-creator Jeff Sutherland notes in his book, Scrum: The Art of Doing Twice the Work in Half the Time
, "One of the pillars of Scrum is that once the team has committed to what they think they can finish in one Sprint, that's it. It cannot be changed, it cannot be added to."
But what happens when you absolutely need to add something to a sprint? Just look at your sprints like you would your grocery list, and toss some thoughtful flexibility into the mix. Imagine going to the store with all the ingredients written down to whip up a batch of buttermilk pancakes for Sunday brunch. Then, while strolling the aisles, you realize flour and syrup didn’t make the list, and you’re nearly out of both. Would you shrug it off and say to yourself, "Well, I didn’t plan to get flour and syrup when I wrote this thing out, and there’s no way I’m getting them now"? No, you would not. A successful brunch depends on transcending the bounds of the list by thinking critically and tossing the missing ingredients into your cart.
Introducing flexibility: Creating the Chaos user story
While I typically spare the Scrum Teams and product owners I work with the pancake analogy, I do advise them to introduce flexibility into their active sprint’s backlog by being willing to introduce what I call the Chaos user story
Creating a Chaos user story means that your team has been interrupted with either an internal or an external to-do item that must be addressed during the active sprint. Internal chaos reveals a sprint planning mistake: The team forgot to pull a key to-do item from their product backlog and add it to their sprint backlog. External chaos spotlights a complete surprise: The team was hit with an unexpected to-do item in the middle of their active sprint.
Whether it’s internal or external, a Chaos user story is created like a typical user story, placed in the active sprint, and made fully visible to the Scrum Team’s members and product owner.
Introducing a Chaos user story into an active sprint may substantially alter the sprint’s goals and delay the completion of other user stories. With this in mind, one should not use the technique lightly. If you do, it’s imperative that both the product owner and all members of the Scrum Team are aware of any Chaos user stories being proposed for their active sprint.
Warning aside, don’t be afraid to try it out, for there are three advantages related to creating a Chaos user story.
- Improve a Scrum Team’s flexibility and framework adoption by allowing interruptions to happen
- Make any interruption to a sprint visible
- Enable a method to track and measure sprint interruptions
Collectively these advantages empower ScrumMasters by improving their ability to spot and remove impediments. Let’s dig into each advantage, because there’s a fair amount of complexity going on whenever a Chaos user story enters the picture.
Improve flexibility and adoption
In my experience, the first advantage of the Chaos user story technique — to enable flexibility within a sprint’s rigid timebox — most benefits those new to Scrum. I’ve often found that the people most hesitant to adopt Scrum’s fast, Lean, and feedback-rich approach have a problem with the notion that they cannot add to sprints once they’re set. Ultimately, the technique is a change-management peace offering. It helps folks in charge who are new to Agile project management feel comfortable with adopting the Scrum framework.
I let these Scrum novices know that, although a sprint needs to stick with only the user stories decided on during the team’s planning session, the Chaos user story is a clever way to accommodate critical
Make interruptions visible
Again, creating a Chaos user story means that other user stories may suffer. However, enacting the chaos technique also means that the critical interruption is brought into the current sprint and assigned to a member of the team; everybody is aware of it and knows who is working on it.
But how do you determine whether an interruption is critical? Look at it together with the key stakeholders — the product owner, Scrum Team, and others, if needed — and determine whether the interruption must be completed during the current sprint. The team’s ScrumMaster must facilitate the discussion of whether an interruption is critical and deserving of being called a Chaos user story. Ultimately, it's the product owner’s call; he or she is the visionary guiding the team’s work and taking responsibility for allowing the creation of a Chaos user story.
To achieve the right amount of visibility for a Chaos user story, make sure it is clearly labeled with the word "Chaos" in the user story's title and any tagging you do. Also, make sure to mention the new Chaos user story during the next Daily Scrum meeting.
Track and prevent interruptions
The third advantage of the Chaos user story technique is my favorite, because it gives teams an analytical tool that accounts for present interruptions to help limit similar, future ones. Put simply, a Chaos user story is an interruption tracking device embedded in a team’s sprint. Over time, these chaos trackers help reveal the patterns that are driving interruptions. Once you understand the causes behind the interruptions, you can plan for them in your future sprints.
It’s the ScrumMaster’s responsibility to lead this analysis. An important part of their role is to eliminate impediments facing the team. A key element to the Chaos user story analysis is the sprint retrospective meeting, when the team openly discusses their completed sprint and needed process improvements. During the sprint retrospective, the ScrumMaster must encourage the Scrum Team and product owner to take an honest look at the Chaos user stories they created over the past several sprints and ask some key questions: Who is interrupting and why? Could we have planned for this interruption? And what do the Chaos user stories have in common? By questioning the nature of the Chaos user stories, the team begins to tease out the interruptions’ patterns and root causes.
If a similar kind of interruption keeps happening, your team is missing something important during the sprint planning sessions. Recurring chaos reveals the cracks in your process and provides you an opportunity to write user stories that transform what was once an unpredictable interruption into a planned to-do item.
So, don’t be afraid of sprint interruptions; just capture them with Chaos user stories and watch them as closely as you would pancakes on a hot griddle.
Joyfully embracing chaos: “Father and Son” by Louise Bourgeois at Seattle’s Olympic Sculpture Park. Photo by Erik Hansen.