Onion

Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. The onion metaphor that is popularly used in agile planning (Cohn’s Planning Onion) can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including: asking, observing, showing and all sorts of hybrids. Using the onion metaphor, the techniques we have explored in the past are the second layer of the onion. However, before getting to the center of the backlog evolution onion, composed of features, epics, and user stories, we need to understand the big picture.  Structured storytelling is effective tool to elicit a description of an outcome and nuances behinds that description, the outer layer in the backlog onion. The outside layer of the backlog evolution onion provides a strategic vision used for budgeting, change management and to provide context to guide the team or teams of teams as the development process progresses.

Budgeting is a strategic form of estimation that most corporate and governmental entities perform.  In order to decide which piece of work to perform and to create a budget for, an organization must have an idea of what will be delivered and the value it will bring. Capturing a narrative story about the outcome and the impact on the organization is a useful tool in the budgeting process. The story replaces the classic back-of-the-napkin description of what the users want often used for budgeting.

Change requires a goal.  A goal is a definition of where you want to go; the outcome that is anticipated. A goal provides direction and a filter to understand the potential impact of constraints.  Generating a story provides the team and their stakeholders with the space to identify and explore what will be delivered, who will be involved and how the organization will need to adapt which is critical for building a change and communication plan to support the work. Somewhere in the middle of any sprint, it can be difficult to remember the ultimate goal of the work that is being done. While the story, the definition of done and the acceptance criteria define tactically what needs to happen, the big picture often is more ethereal. One of the most colorful euphemisms that capture this sentiment is, “When you are up to your backside in alligators it’s difficult to remember that your initial objective was to drain the swamp.” A story provides everyone focused on delivery with a tool that can be quickly referenced when making decisions.

A story is a powerful tool for establishing the big picture while connecting with customers or team members. Stories establish a vision of where we want a journey to end and for how we want to make the journey. Stories provide a platform for making decisions about which work makes the most sense and helps us to predict who will be impacted along the way. Additionally, stories remind us of the context needed to help guide a team as they work through the process of writing, testing and demonstrating code.  All teams need to know the big picture story for the work they are doing.  The big picture is the container that the team will fill with epics, themes and user stories as the backlog evolves.