Once the scrum team has committed to enough work to fill up the sprint, then the backlog gets sealed tight, never to be altered until the next sprint. This can create some sticky situations when new, unanticipated demands emerge mid-sprint. In an article for Scrum Alliance, Erik Hansen proposes using and inserting a “chaos user story” into sprints as a means of directly addressing these unexpected challenges.
Dealing with Madness
To emphasize why the ability to change a sprint midway into it is important, Hansen uses the analogy of shopping for ingredients to make pancakes. If you had a set list of ingredients, but you forgot that you need flour and syrup too and they are not on your list, you are not going to forego those critical pancake ingredients just because they did not make it onto your list. That would defeat the purpose.
Introducing a chaos user story into a sprint allows you to make a sprint item out of these “critical missing ingredient” situations, though it can be used in other critical situations too. Unexpected needs can arise from internal or external places, but in either case, there must be a mechanism to address them. Hansen says that chaos stories particularly provide three major benefits in these situations:
- 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
That first benefit is one that Hansen finds is most useful with new teams, who are reluctant to adopt an approach that does not allow for changes to work in progress. The second benefit enables a team to properly label an interruption as a “critical” task (though what is truly critical is ultimately up to the product owner’s judgement). And Hansen shares this about the final benefit:
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… 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.
This is what I think really gives the chaos user story merit. Otherwise, incorporating standard time buffers into sprint estimates should be enough to accommodate for unexpected interruptions.
You can view the original article here: https://www.scrumalliance.org/community/articles/2017/september/embracing-scrum-chaos