At WillowTree, we ascribe a design process that is ‘fit for purpose’ of the product we’re building and the team for whom we’re building it. Instead of forcing 100% Agile (with a capital A) our design process is adaptable. It suits both project and partner needs by applying the right tools from our agile toolkit at the right times. Because our engagements can start everywhere from green field, just after some level of discovery, or picking up where another team left off — we have developed design tools that work for all of the above.
A User Story Map is one of our tools and works very well for teams who are familiar with agile processes, but less familiar when it comes to scoping a product or a new set of product features.
Using a backlog of user stories, this can be a tremendously valuable tool to fill in gaps or uncertainties in backlogs and ensure teams understand and can visualize the scope at-hand. User Story Maps typically fit in at the beginning of a design sprint when teams have a high-level idea of the scope, but need a way to understand what features will comprise the release(s) better.
Before you get started
To create a user story map, you’ll need a backlog of user stories ( http://www.mariaemerson.com/user-stories/). These can be categorized by persona, business line, functionality, or a host of other categorizations that make sense for your project. They should have a priority associated with them, but you’ll probably find that most lean toward ‘high’ or 'very high.’ That’s totally fine, but flagging the ‘must haves’ will be useful for the mapping exercise. It’s also helpful to consider which stories belong to epics.
For the purposes of the map itself, you can use whatever you want for documentation. The map could be a wall of sticky notes or index cards (I recommend you start with one of these as they are fast and make for easy collaboration), a spreadsheet, or as issues in your favorite issue tracker. It comes down to whatever tool is easiest for you to manage and collaborate through the user story authorship process.
Once you have a solid backlog of user stories and some sense of categorization and prioritization, you’re ready to start mapping. We prefer the task management tool Trello ( http://trello.com) to create our maps, because it generates an online map that is easy to share with your team and incredibly easy to change throughout the mapping process. While Trello isn’t designed for this, it works remarkably well for creating user story maps.
*Note: This should not replace your issue tracker — again, we’re trying to quickly visualize the user story backlog as collections of features, not track progress.
While the user story creation process should be collaborative in nature with a larger product team, it’s also helpful to have a smaller, UX-focused team of 2-3 working on the initial story map. We suggest having a smaller team like this because some user stories may have been created by a non-technical team. It’s helpful to have this team of UX experts think about these user stories in terms of (a) software features and (b) how the features will fit together in a release.
The primary reason we drive this process with the UX team is to ensure our designers are well-steeped and involved in product conception, as opposed to the alternative, which often means being handed a list of design requirements. Including the UX team better positions us to design with business and technical requirements in mind.
Using Trello, start columns for each high-level feature. A column could be an epic, but a column could also contain a few epics—this will largely depend on the scale of the product you’re mapping. If you’ve started with what seems like long list of user stories, this process will start to make the backlog feel much more manageable.
For example, you might have several user stories relating to on-boarding processes or registration flow, so one of your columns should be “Registration and Onboarding”. The user stories that relate to Registration and Onboarding will live in this column.
If you have stories that don’t relate to specific functionality, don’t delete them. Instead, put them in a “UX Principles” column in the map. This will go a long way towards helping your team stay informed of important qualities to have in mind when designing any of the features on the map.
Prioritization And Tagging
In a user story map, there are two axes to prioritization:
left -->right (feature priority)
top -->down (story priority)
Feature priority identifies what the ‘core’ of the product is and helps developers prioritize their sprints accordingly. Story priorities define the priority of specific functionality within a feature.
You’ll also find it valuable to use Trello’s color tags for a few purposes to ensure the team can capture how the map was translated from the backlog. We choose to tag Epics as purple, and ‘Very High Priority’ stories as Red.
Using The Map
Once your map is complete, you have a useful tool that helps product owners visualize their product, determine feature prioritization and identify gaps in user story backlogs. Developers benefit from a tool that gives them a better way to plan sprints. Perhaps most importantly, UX experts gain valuable insight by playing a role in feature prioritization and product conception, ultimately ensuring they can help products come together in UX-sensical ways.