Gathering requirements for a new software solution can seem like a gruelling task, but it doesn’t have to be. Here I’ll show you how, at Box UK, we have worked with our clients to capture the requirements of their “to-be” software systems by using the tried and tested process of “user story mapping” (courtesy of our learnings from Jeff Patton) in our discovery process.
You’ll learn how this approach puts organisations in the best place to start development as quickly as possible, and gain tips to help you on your own software development projects.
Is this post for me?
If any of the following sounds familiar, read on!
- You’re struggling to get to grips with the breadth of requirements for a new software system
- Lengthy requirements documents are bogging you down and you’re not getting the best out of your development teams
- You’re new to story mapping and want to know the basics
What is user story mapping?
Essentially, user story mapping is an agile approach to generating user requirements that will then be used to guide the development of new software. It allows teams to visually “map” the expected behaviour of a user of the system with the aim of identifying tasks and features that users will journey through to reach their goals.
Flexible and versatile, story mapping is an approach embraced across the software industry, from start-ups to global enterprises. It is relied upon as a successful and trusted method for requirements gathering, as well as for communicating ideas in general.
What are the benefits?
Story mapping is useful to help teams:
- See the big picture of a system, as well as how everything fits together
- Collaborate, as the accessible and visual format prompts discussion and generates shared understanding
- Be more efficient, by focusing on developing the detail on the most important features first
- Tell a narrative story about how users interact with a system, and so better empathise with their experience
- Identify unknowns by making it easier to spot holes or uncertainty in functionality, which might have been missed in a flat requirements document
Our clients have had measurable success with the method too. This feedback from a leading membership organisation on a user story mapping session we ran, for example, speaks volumes:
“We have made more progress in five hours than we have done in 18 months.”
If there is one essential thing to remember, it is that user story mapping is used to generate shared understanding among teams. It allows us to visually communicate our ideas to reach a group consensus and shared vision.
What does story mapping involve?
In a session of story mapping, you’ll generate a physical map of your system out of post-its/cards, which can continuously be added to as understanding grows.
Story mapping is a collaborative approach to requirements gathering involving various stakeholders. The make up of participants may change from session to session, but the map is always developed as a team so priorities can be discussed together.
To aid exploration, have visual assets on the walls. These could be designs or wireframes, as well as personas and the product vision (defined in other phases of the discovery process).
User story mapping: a step-by-step guide
To better illustrate the process, I’ve put together a simple step-by-step guide to explain how a story map is built, using a basic ecommerce site as an example. The story map captures the tasks a user would want to complete in order to buy a product on the site.
And please do try this at home! You can follow along with the steps yourself to get a better idea of how it works.
Step 1 – identify tasks
On post-its, identify the tasks a user will undertake in order to purchase an item on a typical ecommerce site. One task per post-it (this is important so that post-its can be reordered to build a narrative in the next steps!). Each post-it therefore represents one task taken as a part of a user’s journey through the system.
Some example tasks:
Step 2 – tell a story
Put your tasks in order, from the first task completed to the last. As you go, use words and sketches to describe the journey the user is taking through the system and why.
Step 3 – share viewpoints
Now it is the next person’s turn to describe how a user goes through the site. If there are duplicates, then this demonstrates consensus, but don’t worry if there are differences of opinion! Different users will use the system differently, so identifying alternatives at this stage helps to build a more accurate picture of how the system could be used.
Step 4 – add more as understanding grows
Combine different perspectives into a linear narrative flow. Group duplicates together, and think about what is missing. Also expand on details, add alternatives and exceptions that hadn’t been considered before. Now you’re starting to build a richer picture of the imagined system, but at this stage still focusing on breadth rather than depth (that comes later!).
Step 5 – group tasks by activity
Some tasks will naturally relate to others, or work together to help users achieve a bigger goal. These can be grouped into “activities”. Activities help to organise groups of tasks normally completed at similar times in order to reach a particular goal. Tasks can also be grouped by a theme or “epic” to demonstrate requirements that the system must also meet, such as GDPR in the below example.
Step 6 – start slicing
“Slicing” allows us to identify tasks relevant only to specific scenarios. This enables more effective prioritisation, to help achieve consensus across the group. Slicing a story map can be done in many ways – for example, you might choose to slice into distinct releases – but in this example we’ve done it by identifying all of the tasks relevant to a specific and essential outcome, which is to purchase a product. In this way, story mapping can help to identify the minimum actions needed to accomplish the goal of a journey.
Step 7 – get in to the detail
Now is your chance to expand more on what happens in these tasks, focusing on those that are most important first. What details are needed from a user? Are there validation rules to consider? Are assets needed? What value does this provide the user?
And that’s it! But what happens next?
It’s important to note that story maps aren’t just valuable in the discovery phase. They’re living documents which can be used through the entirety of a project; expanding as understanding grows. The map, along with the product vision, should always be in sight during development to keep everyone focused in the right direction.
The tasks identified as the most crucial for the initial phases will be explored in the most detail first, but you should continue to add detail to the remaining tasks as development continues. This allows the product team to take advantage of everything that has been learned to date about the product, reflecting any changes in user needs and evolving environments.
In this process, the lengthy requirements document typical of “waterfall” software development is left behind. Requirements prematurely documented, without the benefit of new understanding, will quickly become out of date. However, that doesn’t mean that you should shy away from documentation altogether. I’d recommend digitising your story map so that it’s easier to keep up to date throughout the development process. My colleague uses her digital map to keep a visual picture of how much has been completed so far, as she changes the colour of the post-its depending on their status (unstarted, in progress, completed). Sounds simple, but it is way more effective at communicating progress than a graph!
When it’s agreed that a feature is understood well enough to start development, the highest priority tasks on the story map can be used to make up a backlog of user stories, with the additional details discussed during the session providing the more in-depth acceptance criteria that will be used to test the completeness of the feature.
The story doesn’t end here!
I’ve taken you through the basics of story mapping to start you off, but there are many more ways to use the approach to your advantage. For example, you can use it to map out your current system’s processes in order to spot inefficiencies, or as a roadmapping tool for your company strategy and continuous improvement plans. Whatever you do, story mapping is an effective and collaborative way of building understanding in teams.
Get in touch if you’d like more information, or help with giving it a go!
