Background

As teams adopted agile; units of work became smaller; that created an issue - it became harder to see the big picture. Flat backlogs don’t show how line-items relate to the customer journey or to each other. We needed a way to zoom out, to visualise the entire scope of work, across the customer journey, to help us make sense of it. Enter story maps.

Why Story Map?

• It shows you your products E2E journey for the first time.
• Helps you to identify gaps / holes in functionality
• Helps you identify dependancies on other teams
• It’s can help onboard and orientate your team
• Involve your team and stakeholders in creation
• Crete an environment where it’s safe to challenge, add or edit
• A story map is a great canvas for prioritisation
• You can visualise your MVP, move things in and out of scope whilst imaging the user journey
• It’s a good tool to agree release scope.

How to Create a Story Map

• Backbone of Activities → simple high-level activities users can do in the digital product. The the core set of steps a user must work through to accomplish their goal
• Example: Checkout.
• Steps/Tasks → Under each activity, break down the steps and list the tasks (which can be replace with user stories written on cards)
• Example: Declare delivery address
• Details / tickets / stories → Granular, discrete interactions to complete above
• Example: Postcode/Address Lookup
• Increment/Scope lines → Show what’s included in the next and subsequent releases
• Left/Right Dimension → Shows the user journey, from beginning to end
• High/Low Dimension → Details / tickets are sorted in priority order, from highest at the top to lowest at the bottom.
• Replace tickets with Story Cards → When you’re ready, you can replace your tickets with User Stories - that include more detail like acceptance criteria.

Expanding Your Story Map

Once you have your story map in place, you can add more detail. Just remember that the more you add, the harder it will be to keep up to date.

It’s best to add things that are best visualised across the user journey.

• You can mark development progress (TODO / DONE)
• pin wireframes - to aid understanding
• add persona’s to each step - especially if you have a double-sided product
• add usee pains and gains
• You can add risks, issues and dependencies

It maybe worth adding an ‘ice box’ if you’re building your story map in a workshop → use it to capture big conversations for another day.

More Tips

• Start with a vision and persona’s. If you’re having prioritisation conversations, its helpful to know who you’re building for and why.
• Like all product artefacts - it takes effort for your map be a living document. Try to keep it up to date, but don’t be sentimental. It’s OK to scrap and rebuild a story map if things are changing → it shouldn’t take more than a day, and it’s well worth the cost.

How Story Mapping Supports Agile

• Define early slices of value / MVP
• Easier to adapt to change
• Close cooperation between business and developers
• Face to face interaction

Where to find out more

Jeff Patton is credited with inventing story mapping → here’s his book on the topic…