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…Continue Reading Article