Story Mapping is an Activity Not an Artifact

Reading Time: 2 Minutes

Jeff Patton, a UX/Product luminary and author of User Story Mapping, describes Story Mapping as a pattern that he discovered in the midst of trying to talk with software developers about product development efforts. During these conversations he found it useful to map out various parts of the overall UX using different colored Post-it notes on a wall. While other people (including David Hussman, another product bigwig) discovered this collaboration pattern around the same time, Jeff called it “Story Mapping” in 2007 and went on to write the definitive book on the subject in 2014.

Since Jeff introduced me to Story Mapping about six years ago, I have used the technique over and over on various software projects (including ones at Adaptly), with generally great results. Conversations are clearer and more efficient, shared understanding between team members grows, while circular, “violent agreement”-style conversations become less frequent. We all get in a room, talk through the epic and end up with a well-considered wall of Post-it notes, arranged in a way that we all understand. A typical Story Map may look like this:

story-map-image

Source: Flickr – visualpun.ch

Ideally, you keep all these notes on a wall or table until the thing is built, and then the team can move on to the next theme or epic. Unfortunately, the reality of many organizations is that teams don’t get their own rooms; they have to book a room for a short period of time and then make way for the next meeting. So we end up taking a picture of the wall and preserving the artifact that way. Or if we think ahead, we lay out the Story Map from the beginning on one or two of those large white sticky sheets that you see in many office settings so we can stash it away until the next meeting. Increasingly, teams are seeing value is using one of the software applications designed specifically for Story Mapping, such as Stories on Board or CardBoard It!

Invariably though, I started feeling like we weren’t doing it right. You read about these (seemingly) amazing product/dev teams that can spend days on end laying out the stories and slicing the software releases, maintaining their wall as the product evolves. You start to feel like getting together for an hour here and there and working with 20-30 Post-its isn’t really doing it “right”, but what choice do we have?

Lately, I have become okay with a more casual approach to the artifact creation. Sure I’d love to have a dedicated UX Lab and a collocated multi-disciplinary team on every project, but the reality is you work with what you have. Your lab is the space you are in, and your team is (often) the people who have shown up to the meeting. Your goal is clear communication and aligning the team’s understanding of what you want to build.

Ultimately, the point of all of these Agile UX techniques is not to make cool wall art with Sharpies and scraps of paper. The point is shared understanding by the team. More and more, I am starting to think that the only things that are real in a product dev effort are the things that are in the minds of the team, and the more we can use these simple tools and techniques to get the same things into our team’s heads, the better positioned we are to make a great product.

TL;DR – Story Maps (and other Agile UX techniques) are about facilitating conversations and shared understanding, not necessarily creating and maintaining cool looking artifacts.