With Agile delivery, we trade big upfront design for a “just enough” approach. But how do we make sure we get the right MVP? Story maps provide the answer and many other benefits too!
Story Maps represent a roughly linear view of the steps a customer follows as he or she interacts with the product.
These steps usually equate to Epics in the product backlog and each step gets broken down into smaller tasks, which often become User Stories.
Now that we’ve covered the basics, let’s look at 5 benefits story maps provide.
1. Make prioritization and identification of the MVP easier
Prioritization is reflected on the story map’s y-axis and critical stories move up towards the top.
To deliver quickly and get user feedback as early as possible, it’s critical to identify the MVP. To do so, the team examines the story map to find the minimum functionality that completes the users’ experiences. Below, a good MVP would cut horizontally across the top of the map to create basic registration, payment, session selection, and stats, instead of vertically to create robust registration but no way for a user to make a payment.
The story map helps ensure the MVP or release goal makes sense within the context of the user journey and overall product vision.
2. Visualize the requirements
It’s easier to catch what’s missing and quicker to prioritize when you can see the whole flow at once. No more scrolling through a document trying to remember what you read 20 pages ago.
3. Keep the customer in focus
The story map’s organization ensures that the emphasis remains on the customer’s journey and not on the technical implementation approach.
4. Create shared understanding by getting everyone involved
Even if you start with an existing requirements doc, if you try to create a story map of it, it’s likely many different interpretations will surface. By reviewing the story map together, both business and development see the same thing and areas of confusion become more apparent.
5. Provide a holistic view of the customer journey and a detailed view for project delivery
Large requirement docs provide a ton of detail, but they can be overwhelming, making it difficult to know where to start. User stories are right-sized for delivery, but they’re so small that they can lack context when looked at individually.
Story maps provide both views. The backbone provides the necessary context, while the tasks below show how to break features into small chunks for delivery.
In my next post, I’ll discuss the pros and cons of creating a physical story map vs. a digital one.
Interested in learning more? Join us in March for a User Story Workshop in Arlington, VA.