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.