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. […]
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.
Now that we’ve covered the basics, let’s look at 5 benefits story maps provide.
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.
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.
The story map’s organization ensures that the emphasis remains on the customer’s journey and not on the technical implementation approach.
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.
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.
Getting Agile requirements right can be a challenge but it’s essential as they can make...
Scaling, like Agile itself, can become a target objective rather than the means to an...