User stories spreadsheets are an important part of any project, but they make it difficult to keep your eye on the big picture. Here’s how we’re using story maps to improve the requirements process.
Defining requirements is a key part of user-centred design. At the end of a block of research we have a load of insight into user needs- top tasks, motivations, pain points, emotions and more. Turning this into a tangible list of things to prioritise (then actually do!) is vital.
What we used to do
Our old method will be familiar to anyone who’s ever worked on a website or software – user stories. First, we’d put every requirement in a spreadsheet, one per row. These might be user requirements, business requirements, or technical requirements. Then, we’d get the project team in a room and spend the next few hours prioritising them. The advantage of this approach was the detail. Every requirement- user, business and tech- was graded and ranked in relation to every other requirement. The disadvantage was that the process didn’t serve the needs of its users – the project team. Spending four hours in a hot meeting room updating a spreadsheet is boring. Really, really, boring. Once, somebody said they were going out to send an email and didn’t come back for two hours.
After significant time and effort doing research and sharing our findings this process set us up to ignore user needs, and instead focus on out-of-context details. We needed a new approach.
What we do now
So we decided to try story mapping, based on Jeff Patton’s book, User Story Mapping.
As Patton says, “Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does.” So not only is the process of user story prioritisation a hard slog, it guarantees the project team loses sight of what it is they’re actually making. “Building a user story map,” on the other hand, “helps us focus on the big picture – the product as a whole instead of getting myopically focused on an individual story.”
How does story mapping work?
A user story backlog gives granular detail, but it’s arranged by priority, not context. Different requirements can appear next to each other in the backlog solely because they’re of similar importance. A story map still contains all this detail, but the requirements are grouped by theme. Rather than a list, it’s a narrative.
How do you make a story map?
- Start with an overarching vision
- Break this vision down into a set of goals based on the research (for example top tasks)
- Explain the activities required to reach each goal (again, based on research)
- Break each activity down into the details required to complete it
Here’s an example:
- The overall vision is: ‘A website which offers online training courses for large companies’
- Within this, one goal might be: ‘Finding training courses for your team’
- This goal could be achieved through various activities. For example: ‘Browsing all courses’, ‘Searching for a specific course’, ‘Being recommended courses based on your interests’ etc.
- How a user would complete each activity can then be broken down into individual details. To browse all courses, for example, they might have to see a page listing for every course, filter it by date, filter it by intended audience, and so on. Add as many details as we need to fully explain how an activity will be completed.
What does story mapping look like?
Our story mapping workshops involve lots and lots of sticky notes. These workshops are a great way to get everyone from a project team involved. They’re also pretty much the opposite of staring at a user stories spreadsheet.
Every vision, goal, activity or detail gets its own sticky note. These are then grouped, expanded upon and shuffled around until the full story is told- how the details help users complete an activity, how activities fulfill a particular goal, and how these goals achieve the overall vision.
We also like to create an online backup, which won’t get left on a train and can be kept up-to-date as conversations continue the next day. So after a story mapping workshop we put everything into an online tool called StoriesOnBoard.
Why is story mapping better?
It’s important to point out is that this process doesn’t replace user stories. Tools like ‘StoriesOnBoard’ even let you export your entries into a spreadsheet or JIRA. But a user stories document is a big list of requirements. A story map is an explanation of what needs to be done, why it needs to be done, and how users will do it. It provides context and meaning, in a way that a spreadsheet simply can’t. Story maps stay ‘alive’ throughout a project and beyond, helping us visualise and understand user needs in a way that spreadsheets simply can’t.
This post originally appeared on the Edo blog.