Story Mapping - What I Learned The Hard Way

As Jeff Patton says story mapping is a dead simple idea which allows you to visualize your product via the customer journey.  If you don’t have an understanding of story mapping I’d suggest you start HERE before reading on.  Jeff does a far better job of describing story maps than I could and this post is written to help those familiar with the concept.

Story maps for smaller products can seem almost effortless and practically build themselves.  The product’s simplicity allows you to gloss over uncertainty and still arrive at a valuable view of your product.  The bigger and more complex the product, the more involved the story map.  Small issues become big and differences in approach among team members get amplified.

So if you’re about to kick off a project, here are a few do’s and don’ts to help you frame, map and explore your product through a story map.

DO

1. Do train everyone involved.  Whether you are working with experienced story mappers or not, you NEED to ensure you are approaching the exercise with a common understanding. My recommendation is to take at least 30 minutes and as much as 2-4 hours to train the group going through the exercise.  Don’t hesitate to throw away your first story map and start over to benefit from your experience on the first attempt. This feels almost like it could be it’s own bullet point.
2. Do be very clear on the meaning of your “stickies” and brutally enforce your standard.  The bigger the story map the more important this is to avoid confusion later in your project.  Probably the most common approach is to use activities and high level tasks to form the backbone of your story map and detailed user tasks or user stories to build out the body of the story map.  This approach is laid out well by Jeff Patton’s Story Map One Pager, but this can flex to meet your needs as long as you are crystal clear and everyone is on the same page.
3. Do end on user stories and avoid the abstraction of “features” or “epics” in the detail level of your map.  This isn’t always possible, but it will pay huge dividends down the road when you’re sizing and release planning.
4. Do capture technical or other system constraints and stories even though they may not fit in the story map.  These constraints represent potential work to be done, design constraints, business KPI’s, etc., which are critical to a sprint zero type event.
5. Do be very clear on who your customers are and what they consider valuable. There are a lot of business drivers from the financial to the political to consider, but the only drivers that matter for your story map are those that provide value to the people paying you for your product.

DON’T

1. Don’t start without the right people. I’m usually a big fan of saying the people who show up are the right people, but not here.  You MUST have the right subject matter experts, the product owner, technical experts, and a facilitator at a minimum or your story will have holes and won’t fit your business needs.  It’s worth delaying a day or week to ensure the right people are present and there is sufficient buy-in to the process.
2. Don’t allow artificial breaks in your narrative flow.  This is not usually an issue with smaller story maps, but the bigger the map the more tempting it is to divide and conquer which is always a mistake!  Treat your product like a single product on the map, this will help you avoid duplication and to call out dependencies from day one.
3. Don’t allow pre-story-mapping.  You will have product owners, analysts, etc who will want to get ahead of the game by preparing a story map ahead of the session.  I fell victim to this thinking it’s better to give people something to react to and it will speed us up, trust me, it doesn’t.  The collaboration, the journey, is just as important as the map and the pre-work shuts a portion of that down and eliminates all paths except the one laid out ahead of time.
4. Don’t ignore design.  A lot of people, myself included not long ago, preach that you should exclude design considerations from this process, but talking about design is a natural extension of the story mapping process.  Identify competitors or other industries that have implemented a feature well.  Pin up sketches to help illustrate your idea.  Get designers involved early and often!
5. Don’t feel like the story map has to be perfect or even close to perfect.  One of the smarter people I know says “Perfect is the enemy of good” and a good story map is infinitely better than 100% of your typical backlogs as defined in standard agile methodologies.  Also, remember a good backlog is emergent (part of  DEEP), and your story map should be as well.  It should change, evolve, and grow as you continuously improve and learn more from your customers.

The advice above is based on my experience with framing, mapping, and exploring story maps and is by no means gospel. If you found this post valuable please share it with your network and share your thoughts and experiences in the comments.  You can also find additional agile content and more on SmartOpEx.com.