Embracing Scrum Chaos How to Track and Tame Sprint Interruptions
Photo by Erik Hansen of “Father and Son” by Louise Bourgeois at Seattle’s Olympic Sculpture Park.
By Erik Hansen 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 to 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 and 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 Scrum Master’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 while a Scrum’s sprint backlog is not.
As 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 into 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. 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 your team has been interrupted with either an internal or an external to-do item that must be addressed during the current, active sprint. Internal chaos reveals a sprint planing mistake: the team forgot to pull a key to-do item from their product backlog and into 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. Use carefully 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 both the Product Owner and all members of the Scrum Team are aware of any Chaos User Stories being proposed for their active sprint. Okay, warning aside, don’t be afraid to try it out, for there are three advantages related to creating a Chaos User Story. The technique will: 1. improve a Scrum team’s flexibility and framework adoption by allowing interruptions to happen.
2. make any interruption to a sprint visible. 3. enable a method to track and measure sprint interruptions. Taken together, these advantages empower a Scrum Master by improving their ability to spot and remove impediments. Let’s dig into each advantage, for 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 time-box—benefits those new to Scrum the most. I’ve often found the people most hesitant to adopt Scrum’s fast, lean, and feedback-rich approach have a problem with the notion that sprints can’t be added to once they’re set. Ultimately, the technique is a change-management peace-offering. It helps folks in charge that are new to Agile project management feel comfortable with adopting the Scrum framework. I let these Scrum novices know that, while 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 interruptions. Make interruptions visible Again, creating a Chaos User Story means other user stories may suffer. However, enacting the chaos technique also means 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 if an interruption is critical? Look at it together with the key stakeholders—the Product Owner, Scrum Team, and others if needed—and determine whether or not the interruption absolutely needs to be completed during the current sprint. The team’s Scrum Master must facilitate the discussion of whether or not an interruption is critical and deserving of being called a Chaos User Story. Ultimately, it's the Product Owner’s call: they are the visionary guiding the team’s work, and they need to take responsibility for allowing a Chaos User Story to happen. 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 in order to help limit similar, future ones. Put simply, a Chaos User Stories is an interruption tracking device embedded in a team’s sprint. Over time, these chaos trackers help reveal the patterns driving interruptions. Once you understand the causes behind the interruptions, you can plan for the them in your future sprints. It’s the Scrum Master’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 where the team openly discusses their completed sprint and needed process improvements. During the Sprint Retrospective, the Scrum Master 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? What do the Chaos User Stories have in common?, etc. By questioning the nature of the Chaos User Stories, the team will begin 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 once was 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.
Erik Hansen is a Certified Scrum Master, business consultant, and award-winning writer. He calls Seattle home with his two wonderful boys and fantastic wife. Get in touch with Erik at https://www.linkedin.com/in/erikrhansen/. The Scrum Alliance first published this article on September 5, 2017 in their Member Articles section.