User Story Maps

← Back to Method Diagram

Problem Solving in an Agile Environment

“No development should occur while user needs are in doubt”
Jeff Sutherland – Agile Manifesto signatory and inventor of Scrum

What Jeff was saying is that Agile is a “Development Methodology” not a research, design, testing (Problem Solving) methodology. It should only begin once the Problem Solving method has uncovered and documented credible data and artefacts to represent it, so that the developers have what they need to create the solution correctly and optimally.

But there are many times when organisations just throw everything into agile (small ‘a’) because they believe everything can be done in Agile (big ‘A’), and we have to roll with that and optimise its delivery. Functional User Stories work in and out of Agile, providing developers, stakeholders and project leaders with an assured decision trail, from beginning to end, and a snapshot of the development status in simple graphic terms.

User Journey Maps ensure the developers have all the stories for all the functionality and we have accounted for the dependencies (even if some are just stub stories – we at least know they will be needed and are being considered)

Purpose of a User Story Map 

To show dependencies and the state of User Story delivery, at a glance. User Story Maps are a hierarchical representation of the functional User Stories: their purpose, their relationships, story points, their story ID numbers, the Sprint they will be done in and their parent Epics. These are directly correlated to their Service–>Use Case–>User Journey steps, and in the case of Service Design, to their Service Ecosystem hierarchy and commensurate User Journey.

Of course they are more granular still, as they enable us to break User Journey steps into one or more deliverable, story pointed, functional user story references. They condense a number of important functional tasks and many layers of related data into one hierarchical visual map of the User Story that needs to be developed in Agile.

NB. It is very important to remember that these are not the technical user stories that developers, systems etc, will need to create to ensure a solution is technically deliverable. These are references to the stories that represent the functional behaviours that a Use Case and its User Journey need to be broken into to be developed optimally.

---

Value of a User Story Map

1. Tells developers when the definitions and testing will be complete, so they can begin development.
2. Clearly lays out the story and functional dependencies – preventing stories being done – and redone – out of context and before required information, clarity and dependencies are in place.
3. Avoid assumptions, omitted functionality, forgotten dependencies, and painful/costly rework (or compromise) later.
4. Provides and end to end full chain of data/governance/responsibility and assurance for every feature and deliverable.
5. At a glance reference for stakeholders and project leaders showing progress and remaining work in a simple visual format
6. Issues, blockers and dependencies can be seen immediately and addressed

---

Anatomy of a User Story Map

Each item has connections to dependent stories, sits within the Sprint it is delivered in (this is assigned once we Sprint Plan it into the sprint). It has a reference ID to link it back to it’s Epic or Story full description (most commonly in Jira). It has iconst that show the item type, the story points assigned to deliver it, a link (if there is one) to the story and it’s progress status.

Map Elements

Epic number:

The parent Epic allows us to map how many Use Cases and User Stories are associated with it, have been done and remain. We can trace this back to the Jira entry for further information.

Story number:

This is the same as the full functional User Story (usually stored in Jira), to make sure they are aligned and read the full story details.

Sprint number:

When a story is added to a sprint, we put it within a sprint box and give it the Sprint ID number.

Progress Status Icon:

These show the three states (not done, in progress, done) of stories in the sprint. They give a visual snapshot of the status of the sprint

Story Type Icon:

The little icons show, at a glance, if we are looking at an Epic, Story, Spike or sub-task.

Story Points:

When the Agile team have voted on the points required for each story/task/spike etc, these are added to the Story. This gives a quick and easy view of the size of the story and the expected cadence of each sprint. It is quick and simple to see how many story points are assigned to the sprint and see the cadence of delivery, without digging into Jira.

Link to full functional User Story:

The link allows anyone to connect to the full User Story, which itself links to the associated User Journey (and all its steps) to understand what we are building from this User Story. This allows us to trace the User Story all the way back to the supporting research if necessary. By extension this also provides adherence to governance.

Continued Story:

When a story is too large to be completed in a single sprint, we show its continuation with a dashed orange arrow to the same story in another sprint, where it is continued. Each part has its own story points.

---

Examples

NB. For security clearance and NDA reasons, some elements of the example files may be redacted, changed or removed.