The Product Owner's toolbox to ensure his role: the fundamentals of user story mapping 

The role of the Product Owner is particularly difficult. In simple terms, this role is that of a hub. He centralizes and operates an optimized mix of inputs of very different levels and nature.

To name a few, let's mention two types of inputs: 

• The many time horizons: the here and now (the current sprint and the one to come); the distant endpoint (a product version rich enough to translate the vision and be delivered); the in-between (the various deadlines between these two benchmarks).
• The various issues: in addition to the obvious business issues, which can already be varied and sometimes antagonistic, technical issues must be taken into account in order to ensure that the product is available at a level of quality that is compatible with the Product's objectives (e.g. security, performance, etc.). And a good Product Onwer never loses track of the strategic issues that drive the Product issues. 

For this reason, the activities that a Product Owner carries out simultaneously are varied. They require solid training to carry out this role successfully: the person who has both "hands in the mud" with recipe activities, must also adjust the various levels of planning. And also to give stakeholders a high level view of the strategic product choices. 

So how do you do it as a Product Owner?

In view of the experience of agile approach support, a first response is essential. It is the training of the Product Owner and his coaching to support him in the proper appropriation of the role.  

However, this essential intellectual equipment is not enough because the complexity and volume of information to be managed is such that it requires tools to facilitate its activity. 

A central difficulty is to ensure that the global, strategic and macro level of the Product (or the macro-definition and its macro-planning) coexists with the operational level (or the fine definition and the envisaged planning of each sprint). Typically, the Product Backlog centralizes the themes, epics and user stories. It is an excellent operational planning tool, but it does not sufficiently reflect the structure of the product.  

This is an image that clearly reflects the experience of the Product Owner: the functional logic of the Product Backlog, with which he has reflected and developed the vision, will be blurred by the proliferation of user stories and their distribution in the various sprints.
If we represent each of the user stories by the leaves of a tree, this is equivalent to sweeping up all these leaves and putting them in a big bag. The product logic, which was clear and legible until then while following the main and secondary branches, no longer appears. 

A tool will be particularly useful to answer this need to cross functional coherence and planning: the Story Mapping.  

The fundamentals of user story mapping

The idea here is not to make an exhaustive demonstration of the use of a story mapping. Nevertheless, it is essential to understand the fundamentals of story mapping in order to allow you to initiate it. 

The fundamentals of user story mapping in 8 steps: 

1. Framing the product: defining the vision, the "why" of the product, its objectives.
2. Create one or more personas: this means defining the "who", i.e. the users for whom the product is created. 
3. Build the backbone of your story: describe the entire user journey and related activities.
4. Identify and group activities: define common themes based on the elements identified in the previous step.
5. Break down the themes into epics, then into User Stories. The advantage of reaching a User Stories granularity is (among others) to be able to realize them in a short time, and to bring a tangible user value. 
6. Analyze potential gaps: review the entire user story mapping with a cross-sectional view. This allows the identification of missing elements (user path, size/complexity of the User Stories, user difficulties, etc.).
7. Prioritize the User Stories: using prioritization tools such as MoSCoW. The idea here is to prioritize the User Stories vertically under each theme. From the most important at the top, to the least important at the bottom.
8. Divide the User Stories into iterations or versions. It is to define in a horizontal way the set of User Stories that will constitute your next iterations or versions. This first version can be the MVP (Minimum Viable Product). 

For more information

You can take the time to discover Jeff Patton's articles. As well as his major book on the subjectUser Story mapping. Visualize your user stories to develop the right product.

In short, the complexity of the Product Owner's activities requires a powerful recontextualization tool to rely on at all stages of the project. Story mapping is a powerful vision, strategy and prioritization tool. As such, it is certainly complementary to the Product Backlog, which has the essential role of scheduling operational planning.