Inevitably Agile

somethings are just inevitable …

Story Mapping – step by step

This is a guest post by Cara Turner – Thanks Cara!


A story map is a high level view of the application being developed, from a user’s perspective.

Story Mapping forms part of Release Planning, and is an excellent tool for identifying the Minimal Marketable Features (MMF) for the next Release. This is done with the Product Owner, ideally before starting the development of a new product, and then before each additional Release.

To prepare for the Story Mapping session you should identify beforehand:

– A Character for each of the system users, eg. Cathy, the customer Fleet Manager and System Administrator.

– The major activities done by this user, in line with the sections of the system he/she will use (eg. Dashboard, Vehicle Tracking, System Admin) – write these onto large Index Cards

– Have an idea of what sub-activities each of these major activities includes

You will also need a room with either a large whiteboard, large available piece of wall, or floor area to shuffle the index cards & stickies around on. As always, prestik & a variety of coloured markers help.

The Story Mapping Meeting:


  • To start off the Story Mapping, create an Index Card with each of the Characters
    identified, and stick these up.
  • The card should contain the character’s name, their role, and their main
    responsibilities (eg, [picture])


The top row is called the Skeleton.

  • Select one user and the Index Cards for each of the major activities that they are involved with.
  • Stick these up in order of *frequency that the activities are performed* from Left to Right.

This gives us a view of a typical flow through the system.


The next step is start defining the typical tasks within each of the high level activities.

For Vehicle Tracking, Cathy will need to be able to:

  • view a map
  • view vehicle status
  • activate the relay
  • view live events
  • and include some setup activities


Now we’re ready to break down each of the tasks into steps within the task.

Move the Skeleton card to a separate board / wall, and place the Backbone tasks identified in the previous step in a horizontal line – this time in order of priority for Release.

So “Setup” has moved to the first position, with Map as next priority, and map actions as the lowest.

Under this, we list the steps for each Task

  • What actions or steps can Cathy take for each task
  • Which are highest priority

Write these on stickies, and order vertically by priority.

The Product Owner is now easily able to identify which items are critical for first release, and start getting a feel for future releases. These can be grouped or marked with different coloured dots to identify Release 1, 2 and further priorities.

For Product Backlog Grooming, each of the “Steps” will break down into 3-4 User Stories, so the Product Owner is also able to start ballparking sprint priorities.

And it’s easy to share the vision with the development teams, who can understand the context for each of the steps they will be building.


7 responses to “Story Mapping – step by step

  1. Derek Mahlitz January 27, 2011 at 2:50 pm

    Thanks Cara for sharing this, its a keeper!!

  2. Cara Turner January 27, 2011 at 3:20 pm

    Thanks Derek, glad you find it valuable 😉

    From my side, thanks should definitely also go to Sam – she introduced me to this technique and ran the session so well that by the end I was completely taken with it and wanted to share it with everyone! … and I’m a bit of a lazy writer, so it must have been good 😉

  3. Grant (PG) Rule January 27, 2011 at 5:39 pm

    Hi Cara,

    Thanks for this. ‘Story Mapping’, eh? We used to call it ‘top-down functional decomposition’. Aka ‘action analysis’.

    Good points:
    • it is focused on stakeholder value and requirements
    • it engages (some of the) stakeholders in the requirements elicitation activity & exploration
    • the requirements are visualised
    • it is a joint exercise conducted by end-user and developer stakeholders.

    Not so good points:
    • it encourages stakeholders to think in terms of a pre-supposed solution
    • it is likely to result in automation of the existing (manual?) process & workflow at the expense of thinking through an improved system of work
    • the top-down nature of the decomposition process encourages (forces?) participants to make the big, most risky, decisions first, when information is most sparse
    • there is no suggestion of quantification of either the functional or qualitative requirements (but that can be added easily)
    • there is no attempt to capture and quantify the stakeholders’ desired outcome in terms of strategic goals aka critical success factors.

    A good place to start from to develop a world-class approach to the role of Product Owner (aka Entrepreneurial System Designer). Good luck.

    Best regards,
    Grant (PG) Rule

  4. Cara Turner January 27, 2011 at 5:40 pm

    Um … and the avatar-generator has a sense of humour – I don’t really look like that (or maybe if I’m having a *really* bad day 🙂 )

  5. Cara Turner February 1, 2011 at 10:31 am

    Wow – great feedback!
    Thanks for giving such detailed feedback – I appreciate it.

    In response to the’Not so Good’ points, firstly, I think it’s important to note that this is one tool in the Agile / Scrum kit. The primary benefit is that within the space of an hour or so, a Product Owner can create an overall picture of the entire product, in a format that makes it easy to share the vision. It’s an input into Release Planning, but to treat it as anything more would be to incur the risks you mention.

    It’s agreed up front that because of the many unknowns, this picture is likely to change – but it’s better to have a picture that can change than confusion about what the vision is. I don’t see it as forcing decision making so much as presenting the areas that will need clarity (and risk mitigation) early in the process.

    Agreed that incorporating strategic goals is important – but I worry that it could add more complexity to this simple exercise and divert from the process of clarifying the interaction a particular character would have with the system. I’d assume that strategic goals would have been defined before this exercise – and possibly would fit here as an input into defining the characters.

    As concerns critical success factors, I would say that the Story Map addresses this at a high level by prioritizing Minimal Marketable Features, but which are then elaborated in ongoing Release Planning and Product Backlog Grooming sessions. Similarly Product Backlog Grooming, Sprint Planning and the Sprint cycles would be the forums for ensuring that things like process & workflows are addressed holistically in the system.

    So for me, the Story Map is an effective tool for conversation with all stakeholders, which helps to
    get everyone focused on the same picture, and avoid the negative effects of analysing features in
    too much detail without understanding the product context. From there, the other Scrum & Agile practices
    must still be followed to ensure that the worth is realised.

    I hope this addresses your concerns – I don’t think any one exercise can solve the complex problems in software development, but I do think that this is a highly valuable one to add to the toolbox 😉

    Merci – c’est merveilleux! Je suis honoré! (… and thanks to Google for the translate function :D)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: