Jeff Patton defines Story Mapping as “Talk about user’s journey through your product building a simple model that tells your user’s story as you do.”

Sounds simple right? But, how often do you have a Project Management type who has already defined the stories, and just wants you to agree with the stories they have come up with? Sometimes, this works, but more often than not, the development teams need to know answers to a few questions:

Who for? Why? What? How?

The answers to these questions are really important for several reasons.

It’s important for the development team to know who the users are. Firstly, it provides a point of contact in the business for complex discussions that should not go third hand. Secondly, knowing that there is someone who is actually going to use your solution provides a sense of pride in the product in question. Thirdly, you know that when you receive feedback from someone in a review, that they are an actual user, and not just a stakeholder with outside interests. Whilst these stakeholders are important, they generally want to provide non-functional requests, or understand the benefits to their teams, which can be communicated with your Product Owner in a separate session.

It’s important for the development team to know why a story is created and needs to be played. It helps with prioritisation, and even implementation. It could provide information that helps decide how robust the solution needs to be, how scalable it needs to be, how secure it needs to be.

It’s important for the development team to know what the user actually wants. More often than not a BA or PO will decide what the solution should be without actually consulting any developers. By involving the developers in the conversations with the users, the right product for the user can be developed. It may be that the user doesn’t know what they want, in which case a developer can suggest a simple prototype to get things started. It will promote a feedback cycle with the users, for example: “I really like the way the command line tool processed my files, but I only ever use the same parameters, can they be set as a default?”

It’s important for the development team to know how the product or solution should interact with other systems. Does it need to integrate with an antiquated database? Are there new technologies that the team need to learn? Can some work be outsourced to a specialist? Can we move away from any current techniques, and provide a more modern solution?

Have you ever sat around a screen, with a spreadsheet filled with stories, but absolutely no context? From a developers point of view there is nothing more frustrating than being provided with stories to complete without knowing the who, why, what or how. Mapping the stories, with the users present, ensures that the whole development team start a set of epics, features and stories from the same page, with the same understanding.

However, these meetings need to be will prepared and facilitated, as they can take all day. Sounds expensive right? A team of developers, with the users, PO, Scrum Master, BAs in a meeting for a whole day? I can guarantee that it will be cheaper to run this type of meeting four or five times a year, than to just let a BA or PO create stories for a development team.

Here is my simple recipe for a story mapping session:

Understand The Current Process

By understanding the current process, everyone in the room can start to design a new solution to improve what your users currently do. Encourage the team to ask questions like:

Can you describe the difficulties or pain points?

Is that a time consuming part of the process?

How long typically does it take?

Is it expensive to do?

Does it involve a lot of people?

Start To Map Out The Problems

Get the team to map out problems on post it notes, things that form part of the current process, and things that fall out of the questions the team have asked. If something is a big problem make sure it’s highlighted on the notes.

Write Down Features That Could Solve The Problems

Go over a set of the problems, noting features on post it notes that could help to solve problems. Don’t worry if you have more than one feature idea to solve a problem, that is a good place to be as you can start to give the Product Owner varying solutions to choose from! Make sure that the features are associated to the problems.

Determine The Stories

Start to form high level stories that could complete the features. Try to avoid implementation details, such as libraries or algorithms, but capture things like “Get sheep into field”. Think about how these stories could be accepted by the PO, and think about any non-functional requirements the users have asked for. Make sure the stories are associated with the features.

Estimate The Stories

These don’t have to massively accurate, it’s probably better to bubble sort them based on complexity, known effort and difficulty, any risks the team can describe, and how long similar work has taken, so that you can start to give the Product Owner an idea of how long it could take to deliver an initial cut of the product. You could even just T-Shirt size the stories, so you have a starting point.

In Summary

You’ll find you’ve probably used 4 or 5 post it note pads, and the team will definitely be exhausted at the end of the session, but by the time you leave, each and every person should be on the same page, as to the difficulties the users are experiencing, what a possible solution may be, and how they may achieve it. This is one of the most valuable parts of the entire process. The stories you have created should then fall through your usual refinement sessions to be fleshed out and broken down.