Le rôle du Product Owner est particulièrement ardu. Pour simplifier, ce rôle est celui d’un hub. Il centralise et opère un mix optimisé d’entrants de niveaux et natures très différents.
Pour n’en citer que quelques-uns, mentionnons des entrants de deux types :
- Les nombreux horizons temporels : l’ici et maintenant (le sprint courant et celui à venir) ; le lointain point d’arrivée (une version de produit suffisamment riche pour traduire la vision, et être délivrée) ; l’entre-deux (les différentes échéances entre ces deux repères).
- Les différents enjeux : à côté des évidents enjeux métier, qui peuvent déjà être variés et parfois antagonistes, des enjeux de nature techniques doivent être pris en compte afin d’assurer que le produit soit disponible à un niveau de qualité compatible avec les objectifs Produit (par exemple la sécurité, la performance, etc). Et un bon Product Onwer ne perd, bien sûr, jamais le fil des enjeux stratégiques irriguant les enjeux Produit.
C’est pour cette raison que les activités qu’un Product Owner mène simultanément, sont variées. Elles nécessitent une formation solide pour mener ce rôle à bien : celui qui a à la fois « les mains dans le cambouis » avec des activités de recette, doit aussi ajuster les différents niveaux de planification. Et également donner aux parties prenantes une vision haute des choix stratégique Produit.
Alors comment faire en tant que Product Owner ?
Au vu des expériences d’accompagnement de démarche agile, une première réponse s’impose. C’est la formation du Product Owner et son coaching pour le soutenir dans la bonne appropriation du rôle.
Mais, cet équipement intellectuel indispensable ne suffit pas car la complexité et le volume d’informations à gérer est telle qu’elle nécessite des outils facilitant son activité.
Une difficulté centrale est de faire coexister la bonne gestion du niveau global, stratégique et macro du Produit (ou la macro-définition et sa macro-planification), et le niveau opérationnel (ou la définition fine et la planification envisagée de chacun des sprints). Typiquement, le Product Backlog centralise les thèmes, épics et user stories. Il est un excellent outil de planification opérationnelle mais il ne permet pas de suffisamment rendre compte de la structuration Produit.
Une image qui traduit bien cette expérience que vit le Product Owner : la logique fonctionnelle du Product Backlog, avec laquelle il a réfléchi et décliné la vision, va se trouver brouillée par la prolifération des user stories et leur répartition dans les différents sprints.
Si l’on représente par les feuilles d’un arbre chacune des US, cela équivaut à balayer toutes ces feuilles et les mettre en vrac dans un grand sac. La logique Produit, qui était lisible et claire jusqu’alors tout en suivant du regard les branches principales puis secondaires, n’apparait plus.
Un outil sera particulièrement utile alors pour répondre à ce besoin de croiser la cohérence fonctionnelle et la planification : le Story Mapping.
Les fondamentaux du user story mapping
L’idée ici n’est pas de faire une démonstration exhaustive de l’usage d’un story mapping. Néanmoins, il est essentiel de comprendre les fondamentaux de la réalisation de ce dernier afin de vous permettre de l’initier.
Les fondamentaux du user story mapping en 8 étapes :
- Cadrer le produit : définir la vision, c’est le “pourquoi” du produit, ses objectifs.
- Créer un ou des personas : c’est définir le “qui”, soit des utilisateurs pour lesquels on créé le produit.
- Construire la colonne vertébrale de votre histoire : décrire l’ensemble du parcours utilisateur et les activités s’y rattachant.
- Identifier et regrouper les activités : définir des thèmes communs basés sur les éléments identifiés lors de l’étape précédente.
- Décomposer les thèmes en epics, puis en User Stories. L’intérêt d’atteindre une granularité de type User Stories a pour avantage (entre autres) de pouvoir les réaliser dans un délai court, et, apporter une valeur utilisateur tangible.
- Analyser les potentiels écarts : revoir l’ensemble du user story mapping avec des regards croisés. Cela permet l’identification des éléments manquants (parcours utilisateur, taille/complexité des User Stories, difficultés utilisateurs, etc…).
- Hiérarchiser les User Stories : à l’aide d’outils de priorisation de type MoSCoW. Il s’agit ici de prioriser à la verticale les User Stories sous chaque thème. Du plus important en haut, au moins important en bas.
- Répartir les User Stories en itérations ou versions. C’est définir de façon horizontale l’ensemble des User Stories qui constitueront vos prochaines itérations ou versions. Cette première version peut être constituer le MVP (Minimum Viable Product).
Pour plus d’informations
Vous pouvez prendre le temps de découvrir les articles de Jeff Patton. Ainsi que son ouvrage majeur sur le sujet User Story mapping. Visualisez vos user stories pour développer le bon produit.
En résumé, la complexité des activités du Product Owner nécessite un outil puissant de recontextualisation sur lequel s’appuyer à toutes les étapes du projet. Le story mapping est un outil de vision, de stratégie, de priorisation puisant. À ce titre, il est assurément complémentaire du Backlog de Produit qui lui a vocation essentielle à ordonnancer la planification opérationnelle.
