Say hello to the new Tempo! LiquidPlanner is now Portfolio Manager. Learn More
5 Reasons to Use Story Maps for Your Next Project | LiquidPlanner

The blog for passionate planners

Tips, stories, and insights to better manage work, improve productivity and enhance collaboration.

5 Reasons to Use Story Maps for Your Next Project

Using Story Maps for Your Project

Ever since I attended the Agile and Beyond 2015 conference, I’ve become engrossed in story maps.

I don’t think I’ll ever gather project requirements or plan software releases any other way. Whenever I mention “gathering requirements,” IT professionals tend to tune out at the prospect of defining customer requirements in a mammoth Microsoft Word document.

For years, the IT industry has been inundated with requirement templates and Word documents. A requirements document that’s been signed off on is also saddled with some unsettling expectation: that all requirements are perfectly stated, agreed to with the business customer and then committed for delivery.

What happens if the requirements change? Ah-ah-ah!  You’d better have change control and a list of approvals!

Reality check

Requirements always change as teams and customers learn more about the system as the project progresses. It’s not exactly realistic to expect project teams to work off a static requirements list and then deliver functional software months later. There has to be a better way—a more Agile way to address end-user requirements!

Story maps let teams plan a software release using user stories to represent customer requirements. User stories are typically written on index cards, sticky notes or developed as virtual cards (check out the Card View feature in LiquidPlanner). A story map puts all these requirements in order horizontally and represents the sophistication of the solution vertically.

The following example defines an email system’s user stories and organized them across:

  • task groupings (blue cards)
  • major tasks (orange cards)
  • subsequent features (white cards).

Story maps 1
Made with StoriesOnBoard, user storing mapping software.

I’ve found a lot of benefits from combining user stories with story maps to gather, manage and plan requirements across software releases.

Here are five benefits to story mapping your next project.

1. Delivers the really important requirements first

Story maps let teams prioritize the important requirements first, and then start validating the requirements with working software. In Waterfall software development and project management, the team documents all the requirements first and then starts development. All the features are delivered at the same time. With a story map, teams can prioritize the most important features first and deliver code based on the prioritized features.

Story maps 2

These features can be built across an end-to-end business process rather than developing one function completely. In the email system example, Release A includes all the major features required for a simple email system. Subsequent releases deliver improved functionality in slices. By following this approach, teams can validate the system, and the business process works at a high level while continuing to be refined in subsequent iterations.

2. Splits large requirements into small slices

I like user stories and story maps because it forces you to be brief in the requirement description. Give me a stack of index cards over a 100-page business requirements document anytime. If the business requirement is too complex to be stated on a single card, simply break it up into two cards. Story maps let you organize requirements into groups and then deliver in smaller releases.

3. Defers the less important requirements to another release

Since the requirements are defined in smaller increments, it becomes easier to defer less important requirements to a future release. By prioritizing the important requirements first and moving the lower priority requirements to future releases, the project team has a greater success at delivering a product the customer needs versus a partial product with robust bells and whistles.

Story maps 3

If project funding is suddenly reduced or eliminated, the end customer still benefits through working software based on prioritized requirements. In the email system example, if funding was eliminated and I couldn’t deliver Release C, then I’d still have a working product. This would be difficult to manage in a traditional Waterfall-based software project. The story map process makes it is much easier to organize requirements into prioritized releases than in traditional project scheduling.

4. Improves communication with the customer

Story maps also help improve communication with the customer. Since each requirement is aligned to specific process steps and releases, the customer understands what functionality will be delivered with each release. If the customer wants a different feature delivered earlier, the customer can simply re-prioritize that feature in the story map.

5. Helps you visualize the product or system roadmap

If you handed me a 100-page requirements document or a spreadsheet inventory of requirements and asked me to approve the document, what is the probability of success? Somewhere around page 10, I’d start to skim the document and likely miss an important requirement that I’d be held accountable to during the development phase. This approach simply doesn’t make sense because it’s difficult to convey how requirements align to the system in a spreadsheet or text document.

With a story map, however, the focus is smaller and the customer can visually understand the requirements being delivered in the first release, second release and subsequent releases. By focusing on the releases, the customer can pay more attention to the relevant requirements. During Release A in the email system example, the customer can focus on the high priority features that comprise the initial release.

Story maps 4

Once these requirements are implemented as working software, the customer and the project team have a better idea of how to adjust the product or system roadmap. A lower priority feature can be reprioritized into an earlier release since the team has a better understanding of how the technical layers will work. Try doing that with a Word document!

Learn more about story maps

Story mapping is a useful technique and I’m looking forward to applying it to portfolio planning and strategic planning in addition to the software roadmap approach. If you’d like to explore story mapping further, here are some books and articles.

Story maps work well with teams who use an Agile approach–a way to move fast, be more responsive, improve processes and learn from each iteration. If you’re interested in the Agile-fication of your team or organization, learn more! Download our eBook, Agile for Everyone.


Get a live walkthrough with a Product Advisor


Experience all the features for 14 days

More Articles