It’s hard for a product owner to keep perspective when looking at a stacked list of features needed in a product, much less communicate the high level roadmap to others. Backlogs are too granular and, frequently, just too long. Often they contain many capabilities that will never be delivered!
A product’s user stories may be broken up numerous ways: by very narrow slivers of end-to-end functionality, by seams in the technical architecture, or by some other approach.
It’s hard to look at the list and see what the end result is. Perspective is needed to see the big picture.
All the features may be captured within a roadmap, but even a roadmap doesn’t always paint a complete picture of how all the capabilities tie together. One of the best tools to provide context around user stories is the User Story Map.
What’s a User Story Map?
A user story map is a visual representation of user behaviors intended to show, at a glance, the capabilities needed within a software product. Buckets of functionality are depicted left to right, ideally in a sequence that follows a typical user path through the system. This makes the map easy to explain and easy to understand.
Sample User Story Map for a Document Management Product
Jeff Patton described the usefulness of this technique in 2009:
….In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.”
“After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag – then cut down the tree.”
Dropping down from each category across the top are sub-categories related to each bucket, and the user stories that fall within them. Categories can be divided into as many levels as necessary, but given the goal is summary and communication, the fewer the better.
At design time, this tool also helps the product team to review and ensure they’ve captured all the needs. It’s hard to look at a simple ranked or unranked list and find what’s missing, but by separating and grouping items, it becomes easy to see.
Generally, you’re including capabilities here that are independent of their implementation. When represented in the product backlog, the team will require more granularity to properly manage development. But because this is a communication tool, you’ll want to keep it agnostic of implementation approach.
Prioritizing toward MMF
As you add meat to the bones, you start to see the capabilities needed to deliver value in each bucket. Continuing this process, you can then begin to use the story map as a management tool.
By drawing a line under the lowest story in every bucket that is a “must have,” you can visually represent the capabilities required to reach specific milestones. For example, this is a common way to represent, visually and openly, exactly what is required to reach “minimum marketable features.” Some companies use this milestone to represent the moment when their marketing campaign can begin – and this tool supports conducting a countdown (burndown) towards the milestone.
What about MVP?
In the case of an iterative, learning tool like an Minimum Viable Product, this may not be as applicable. The MVP is designed to expedite learning, so there are two primary vectors that prevent this from being useful:
- You don’t know exactly what features will be needed
- You don’t know if your initial implementation of a feature will be the optimal solution
When building towards MMF in a mature space, the first factor doesn’t apply: You know what features are required as “table stakes.” Often times in enterprise B2B software products, because the balance of power favors the buyer rather than the user, the implementation of each feature may simply require “good enough” without being optimal. Whereas a startup might go back and rework something that is just “good enough,” it may be more important in some cases to go forward with the feature as-is and have a product in market.
Since you’ve described the capabilities from the perspective of the user, despite that this isn’t really a way to describe an evolving MVP, it may still help to describe the viability of the solution. If you don’t get far enough into any of the high level categories, you may not have a product that is robust enough to meet the needs of users.
The user story map can be considered a living artifact. As each capability is completed in the product, the corresponding card can be color coded to indicate complete. Those currently in progress can be marked with a different color. Now the artifact is a communication tool not only of the entire capability of the system, but is also a window into the current progress and how much has already been achieved.
Since this is generally applied to products prior to release, rather than complete products that require incremental improvements, it isn’t as applicable to a product already in market.
What is your experience with the user story map?
Image source: Flickr