Build story maps

There are two flavors of the story-map exercise:

• Generative story-mapping. The client is aware of challenges and opportunities but does not have a prescribed solution.
• Summative story-mapping. The client team is in alignment and has defined a prescribed solution that we simply need to extract, document, and estimate.

Tom Wujec has an excellent TED Talk that describes how to achieve alignment with large groups. He says that the most effective means of achieving shared understanding in a group is to break ideas down into individual nodes or cards and then create conversations around those cards. We embrace this idea in Lean Requirements by using simple tools that don’t get in the way.

The goal is to use tools that encourage the flow of conversation and visualization, such as whiteboards, sticky notes, markers, and stickers. These materials simplify the process of generating and organizing ideas by reducing the effort to iterate and improve.

Sticky notes are small, and markers are fat—using them together forces participants to keep ideas short, simple, and self-contained so that they can be easily reorganized.

Sample domain

To illustrate generative or summative story-mapping, imagine an airline company wants to rebuild its existing online booking experience. The vision-setting exercise is complete, and the foundations of a charter are in place.

Generative story-mapping process (Divergent thinking)

With users in mind, start brainstorming solutions and feature ideas. Give each participant a stack of sticky notes, a marker, and ten minutes to generate new ideas. To keep ideas concise and actionable, request that each note includes a verb and noun pair—for example, “view reports,” “export list,” or “update profile.” Encourage silence so that participants aren’t distracted with side conversations and don’t shoot down ideas. This is a time for independent, free-flow thinking. The golden rule is that no idea is a bad idea.

One at a time, each participant approaches the board and presents ideas to the group, which creates engagement and a sense of ownership. The goal is to ensure everyone understands each idea. The prospect’s team members are also encouraged to piggyback on ideas. Again, the focus is not to discredit but to understand—no matter how far-fetched the idea is.

The Devbridge workshop facilitator should create group topics in another color to categorize similar topics, with the goal being for everyone to understand each idea—not to filter out bad ideas. Create an affinity map that groups similar stories into features, and similar features into epics.

Then rearrange the epics, features, and stories into a story map. Epics and features flow from left to right in a logical user path—such as searching, checkout, and booking. The stories under each feature are also arranged in a logical flow to illustrate the entire scope of our ideas.

It is a useful idea to feature a legend to the side of the story map. To group the stories more effectively, create and recreate features. If you notice a feature with more than ten stories, break it down further.

Summative story mapping process (Convergent thinking)

These are workshops with a very specific and prescribed objective. The only difference in the process here is that the facilitator writes out all ideas as the stakeholders dictate them instead of opening the floor for presentations. Because the group is likely aligned, there is no need to have each individual go over the same stories.

Going too deep

One stat often shared at the office is that a workshop uncovers around 60 percent of the requirements needed for the product. Is that enough? It’s up for debate and depends on many variables—maturity of organization, comfort with Agile delivery, existing financial constraints, and much more. Upon completion of the workshop, the collective team should have a clear understanding of the challenge and solution. Trying to uncover all unknowns leads to waterfall delivery—overdocumenting, overanalyzing, delaying the build process. Meaningful working code is the objective—not utter and complete documentation of all edge cases.

A story map should define just enough requirements to get the build started.

Set that expectation as part of the exercise and clearly communicate that the product will continue to evolve over time. Demonstrating velocity and exposing working software to users will further refine the backlog and roadmap. This ultimately results in new discoveries that require adjustments to the backlog, potentially reprioritizing the remaining scope, moving new discoveries higher in the priority chain, and de-scoping some features from the MVP to stay within the desired spend.

The workshop is not the place to start writing acceptance criteria for individual stories—if you’re that deep, it’s time to resurface for air.

Writing good stories

INVEST is a good mnemonic to remember what a quality story for an Agile software project looks like:

• Independent: Self-contained in a way that does not allow for inherent dependency on other stories.
• Negotiable: Stories are not explicit contracts; they should leave space for discussion.
• Valuable: A story must deliver value to the stakeholders.
• Estimable: You must always be able to estimate the size of a story.
• Small: Stories should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
• Testable: The story must provide the necessary information to make test development possible.

Here are a couple of best practices (applicable to refinement sessions):

• Stories should be small enough that a single story does not take more than 50 percent of a sprint for a single individual.
• Any given story can ideally be completed by any given engineer on the team. This indicates a desired level of maturity for the team, but team leads should run traffic control if this is not the case.

In a short period, the team has worked to define a solution, get cross-functional alignment on scope and priorities, and create a level of shared understanding not possible in traditional requirement methods.