Storymapping — a Guide
Best practices on the use of Storymaps
It’s no secret that I am not a fan of Storymaps however, as their use is recommended frequently and they are by far not the worst tool to visualise scope and priorities, I feel it is worth discussing how they should be employed if we decide to do so.
Why Storymap
Storymaps help with the following challenges we face when managing solution design and delivery:
Need to deliver value
The starting point of a storymap are goals (user and business) in the context of a specific user journey. By considering both we deliver valuable things.Dealing with resource constraints (time/money)
A storymap helps to identify all capabilities that we could provide but then forces us to rank / prioritise them in the context of value, complexity, dependencies and cost.Successful delivery is built on good communication and work management
Storymaps are an efficient and effective way to visualise, communicate and collaborate on scope and related priorities thus ensuring alignment within and across teams.Manage scope in an environment of change
Storymaps allows us to easily identify and manage scope changes as we encounter them and thus built product evolution into our process.
What is a Storymap made of?
The scaffold
In its most simplistic form a storymap is two-dimensional map that maps an individual user journey (expressed as user-centric activities) horizontally and expectations towards features supporting these activities (expressed as epics or stories) vertically.
Value Focus
A quality Storymap is solidly set in value we want to deliver to users by identifying and linking business goals, user goals and user personas thus providing a rationale against which we can check/justify each item on our roadmap. If it it doesn’t contribute it shouldn’t be there.
Bringing it together
The focus on end2end user journey ensures narrative-complete functionality is being delivered and, focus on objectives / goals and users ensures (only) valuable things are delivered.
What we show on a Storymap
The key items are:
Activities are the top level actions a user conducts. Written from the user’s perspective they form the backbone of the map and are the milestones along the user journey. If the Storymap is very ‘short’ these may be optional. Example: ‘Browse catalogue’ > ‘Select Product’ > ‘Pay for Product’
Tasks are detailed steps taken within an Activity
E.g. ‘Pay for Product’ can be decomposed into tasks such as ‘Select Payment type > Select Currency > Enter payment details > Complete Verified by Visa’.
Stories are detailed actions within each task or rather expectations towards offered capabilities a user has when accomplishing a task.
They should be should be written in the classic format ‘As a <user> I want to <action> so that <rationale / value>’. It is ok to assign summary titles on physical post its, e.g. ‘As a subscriber I want to log in so that I can access my customer profile’ summaried as ‘Login’.
What else can we show on a storymap:
Epics/Features which are defined within the VSTS world as ‘big’ stories can be treated like stories for the purpose of Storymapping (though if they are too big we may want to break them down).
Themes which are defined as cross-cutting concerns can be used to highlight related items on a storymap where helpful.
Implementation Tasks While traditionally (implementation) tasks were captured on storymaps I recommend against it. Storymaps are for scoping not detailed planning. Hence only scope (epics / stories) should be captured.
Story Evolution and Dependencies
Storymaps can express evolution of individual features / stories over time by drawing arrows between the related items if deemed helpful.
Meta Information
We can also express, as helpful, meta information such as:
item status (read, in progress, completred)
applicable user persona
Quality Storymaps
A Storymap covers a singe journey with discrete goal
There is no hard and fast rule how long the journey a Storymap covers should be, but generally speaking a single Storymap should represent one persona’s narrative-complete journey while achieving a discrete goal. Loosely related sub-domains are often good boundaries for Storymaps, e.g. ‘Buy Product’ vs. ‘Return Product’. However, if ‘Buy Product’ gets too large we can to break it down into ‘Find Product’ and ‘Purchase Product’.
A Storymap is not a process model
The storymap backbone expresses a flow of activities in a highly idealised and abstracted manner. They are not a bmpn process model or UML activity diagram outlining all possible flows. Storymaps are tools to identify and manage scope, not tools for analysis and solution design.
This means that in general we do not map conditional flows or alternative scenarios and exceptions within the stories activities and tasks. Such detail will be captured either as individual stories or scenarios within stories.
Note: One concern I have in the way Storymaps are being sold as the key scoping tool by many coaches is that there is a risk that we ignore detailed UX thinking and analysis required for good solution design.
Be user-centric
Ideally a Storymap represents all activities from the viewpoint of a user persona, however there are cases where this can lead to awkward making up of user-centric activities. So we can break this rule:
Assume there was a feature where a system does something, say send an email, run a cron-job or lock an account based on too many times incorrect password entry. There are three ways to deal with this:
By default we should ask question of ‘who benefits from this and how?’ which in most case will allow us to word the item in a user-centric way. Remember there is very little that happens without benefiting at least some user.
E.g. sending that email which really is about ‘Receive order confirmation’. Also, write ‘View chart’, not ‘Present chart’!There are also items that are not activities in their own right but business rules or special cases associate another activity. These we should treat as alternative/exception scenarios the respective story.
E.g. locking an account, which is a scenario within ‘Login’Finally, it is totally ok to represent the system as a ‘user’ within our storymap and define system-based activities in cases where there are important, major system activities that we want to treat / highlight as individual activity, task or story. However, if many activities or tasks of this type it may be well the case that we are not sufficiently user-centric or at implementation level! So use sparingly!
E.g. cron job, heavy-weight data transformation, system backup.
Stay solution-neutral(ish)
Although we are representing a real-world flow of activities, we should articulate tasks, activities and needs as solution neutral as possible. After all, this is analysis / scoping; solution design comes later.
E.g. ‘View earnings’ instead of ‘View a line-chart indicating earnings in blue and losses in red’.
Use multiple maps
While there are descriptions of storymaps modelling entire business-(unit)-wide processes end-to-end, I don’t think this is sustainable as such maps can become massive and tend to loose focus. Where we are looking at a vast domain, I suggest to create high-level map spanning the domain and detailed maps to model respective parts.
Also, we may want to abstract / expand related activities: A classical example is that a user may want to ‘Read an article’ on a news website. This is a single activity. Of course, behind the scenes, the content editors are doing activities to make this article available. By default it is always good to focus on the user that actually generates value (in this case the reader), so we start with a map such as
Login>Search>ReadArticle
If we find that there is only a single activity needed, i.e. Publish Article and this capability exists already or there are only a limited number of changes in this area, we may be happy to handle this within ‘Read Article’.
If, however, there were many activities and new features and even multiple users (publisher, editor, translator) then we should consider this as separate storymaps:
E.g. Login>CreateArticle>UploadImages>EnterCopy>Publish>…
We can, of course, reference the two maps, i.e. have a placeholder / link item to the second map under ‘Read Article’.
Prioritisation and Releases
As outlined above, ‘time’ flows vertically downwards on a Storymap. We can use this by
simply rank Stories (within or across tasks)
introduce rows (swimlanes) that indicate timeboxes, releases, major priorities.
In fact, we can support the grouping into releases by assigning a ‘release theme or goal’, e.g. present products, sell products online, support pick up in storeStorymaps can have a swimlane to indicate the MVP, and / or may have a ‘maybe at some point in the future / catch all bucket’, often called backlog or icebox.
Tooling — Physcial vs Virtual
While I expect every good PO to have a physical Storymap (and a Kanban or Scrum board) near their desk, I do understand that there are complexities with this approach in case of distributed teams.
While Storymaps can be created in literally any software that can draw boxes, there are many dedicated tools such as featuremap (some more some less easy to use). While storymapping is often an up-front exercise it is worth considering the use of a storymapping tool that is integrated with the actual product backlog to avoid duplication of work and inconsistencies. SpecMap for instance is VSTS’s Storymapping tool (and while quite limited, provides the advantage of integrating with the VSTS backlog).