Using Story Maps for Release Planning
User Story Mapping is my favorite method to unpack a large, vague design problem into a form everyone understands well enough to solve. You’re not done designing once you have your story map, but you have a systematic way to know when you’ll be done.
In this article, I’ll explain how I bring all the pieces together to go from initial concept to release: starting with a Story Map, identifying the features and documenting them with a Feature Overview, and finally writing Release Notes to explain which features ship together at the same time.
It All Starts with a Map
If you’re familiar with User Story Mapping — and if you’re not, you might as well bail on this article and at least take a few minutes to read this blog post — you know that the final story map looks something like this:
Our extension to the story mapping method adds design details underneath the relevant user activity, partially to make the ideas more concrete and partially to make them estimable by our development leads:
In most cases, the larger sticky note underneath becomes a feature, which gets documented as a Feature Overview once the design has been refined and “thought through” to a reasonable level of detail. At this point, most of the different screen states and user paths will have received a basic design treatment, so any discussion of how the feature is supposed to work can be fairly detailed.
If we can build some form of prototype in a few days, we tend to do that to make those detailed discussions go more smoothly. Sign-off discussions, in particular, are always centered around clickable prototypes. That said, we continue to push the envelope and loop in our developers and testers earlier and earlier, when the concept is just a sketch. Obviously, it’s easier to integrate their ideas and feedback the earlier they’re included, especially if they bring a fundamentally new concept to the table.
Grouping Features into Modules for a Release
Once each feature is designed, we flip back to the story map to see which features need to ship together so that the user can achieve the outcomes and goals that are important to them. (I love how story maps make this grouping crystal clear!) One level up from there, it’s not hard to group the outcomes together into themes that logically hang together as a release.
Typically, our themes end up as modules of related features, though as a product evolves you may have themes like “refreshing the look and feel” or “speed and efficiency.”
Houston, We Have Sign-Off
However you group the features, eventually product management signs off on the designs for all the features that will ship together. Once this happens, we create a Release Notes document broken into a few basic sections:
- New Features, including the name of the feature (to brand it), the benefit users get from it, and a quick description of what it does (read this article for more details)
- Improvements, if an existing feature was changed in an important way
- Bug Fixes, if they’re notable
- Technical Details, including installation and configuration instructions
At the moment of sign-off, usually only the first two sections can be filled in. Even still, it’s worth it for the technical team to have a place to capture important technical details, even in a “draft” state.
Don’t Forget to Code
Obviously I’m skipping over the enormous effort involved in actually coding the features, testing them, iterating on them, etc. That work is necessary — but not sufficient — for a great product. The best products and features begin with a clear, compelling “North Star” as to what valuable outcomes they enable, and every ounce of effort from the team makes progress toward that. This is our method of keeping the team on track.
