Conseil pour les chefs de produit : associez les backlogs de produit à la vision du produit

L'un des défis constants pour une équipe de développement agile basée sur un produit est de faire correspondre ce qu'elle fait « actuellement » à ce que le produit est censé devenir, disons, dans 2-3 ans.

Il ne s'agit pas d'équipes qui ne savent pas sur quoi elles travaillent, mais plutôt du fait qu'elles peuvent rester trop concentrées sur leurs tâches quotidiennes, sapant invariablement la sensibilité de l'impact de leur travail « actuel » dans l'ensemble . Les décisions ou les choix effectués lors de l'exécution aujourd'hui peuvent avoir un impact futur important, en particulier lorsque le produit évolue.

Prenons un exemple concret.

Je faisais partie d'une équipe agile qui essayait d' introduire un service de traduction de texte pour le contenu du site . La décision a été prise et un outil de traduction automatique tiers a été utilisé. Cependant, la feuille de route du produit a finalement mentionné qu'à l'avenir, les utilisateurs devraient pouvoir corriger et fournir leur propre traduction contextuelle, ce qui signifie que la capacité de traduction devrait disposer d'une intelligence artificielle afin qu'elle puisse apprendre par elle-même, en fonction des commentaires.
Compte tenu de cette évolution, le choix effectué n'était pas judicieux et nécessitait donc un certain degré de retravail, car la vue d'ensemble n'était pas liée à ce que l'équipe agile était chargée de faire dans le sprint.

On peut affirmer que les équipes peuvent faire un effort conscient pour obtenir ces informations, mais le fait est que pourquoi ces objectifs « à long terme » ne peuvent-ils pas être capturés dans les outils et tableaux de bord agiles existants ?

Les équipes agiles exécutent des tâches bien définies et spécifiques dans un cycle de développement mais cela signifie-t-il que cela doit se faire au prix d'une indifférence à l'évolution du produit ? Non je ne pense pas.

D'après ce que je sais, il n'y a pas d'outil ou de cadre rapide qui préconise ou recommande cette information à l'équipe agile, dans son fonctionnement quotidien, mais une telle vue peut-elle être créée dans la vue existante ? Ça vaut le coup d'essayer? Voyons comment pouvons-nous le faire.

Nous commencerons par l'artefact le plus courant en agile - le backlog de produit.
Selon le SCRUM Institute, un backlog de produit est la liste des choses qui doivent être faites dans un projet. Ces éléments peuvent inclure des améliorations et/ou des bogues. Une liste numérotée n'est utile que si l'équipe connaît la structure de priorité des éléments. C'est là qu'intervient le Product Owner qui a la responsabilité globale de travailler avec les parties prenantes pour obtenir des exigences claires, résoudre les interdépendances et obtenir une liste de priorités pour les éléments du backlog de produit.

Il est possible qu'au cours de ce processus, un élément de travail plus important et dépendant soit ensuite décomposé en petites parties afin qu'il soit facile à développer pour l'équipe. Ces éléments du backlog de produit sont décomposés en plus petits morceaux et exécutés dans des cycles de sprint allant de deux à quatre semaines, répondant à la composante « comment » du développement de produit.

D'autre part, les éléments du backlog de produit sont également mappés au «vrai nord» du produit, souvent appelé vision du produit. Il s'agit de l'état souhaité du produit qui est souvent atteint grâce à plusieurs versions et qui est étroitement lié à ce que le public cible ou les clients veulent et à la valeur qu'il leur apporte.

Cette chaîne d'éléments reliant l'équipe agile aux clients (y compris les backlogs de produit et la vision) peut être représentée comme :

Lien à distance entre une équipe agile et ce dont le client a besoin…

En l'absence d'une vue qui relie clairement les sprints à la vision du produit, les Product Owners courent souvent le risque de trop se concentrer sur la partie "comment" et de perdre de vue l'objectif plus large et important du "quoi", qui peut conduire à une hiérarchisation erronée.

L'approche dont je parle ici consiste à créer une vue simple mais puissante qui relie les deux composants. C'est ce qu'on appelle la matrice de vision du produit (PVM). L'objectif est de lier la vision du produit à des éléments de développement granulaires. Cette matrice devient un facteur clé dans l'analyse des progrès de l'équipe en matière de développement de produits. Il sert également de tableau de bord du produit pour la haute direction de l'organisation et les tient informés de la possibilité d'atteindre les objectifs du produit.

Comme son nom l'indique, PVM est une matrice où les colonnes représentent les dimensions (de micro à macro) qui sont capturées. Comprenons PVM à l'aide d'une application de commande de nourriture où la vision est de fournir une expérience alimentaire aux utilisateurs, et le point de départ est la commande de nourriture. L'exemple de matrice ressemble à ceci :

La matrice de vision produit peut avoir les champs suivants :

• Version du produit : il s'agit de la version du produit qui constitue l'étape de publication officielle et correspond souvent à celle que le client reçoit.
• Big Rock Item : Il s'agit de la catégorie ou du thème auquel appartient également une fonctionnalité. Ces éléments peuvent également être les domaines de besoin de produit à long terme de la vision du produit.
• Fonctionnalité : il s'agit de la fonctionnalité du produit en cours de développement. L'élément peut appartenir à un ou plusieurs thèmes (gros éléments rocheux).
• ID de sprint : il s'agit du numéro de sprint dans lequel une fonctionnalité est en cours de développement.
• Statut de développement : ce champ indique la progression du développement (planifié, conception terminée, développement terminé, testé et publié).

Notez que la structure de la matrice est indicative ici. On peut être plus créatif dans l'identification des colonnes qui peuvent capturer la vision du produit.

L'avantage de cette approche est la visibilité claire de chaque membre de l'équipe sur les objectifs globaux du produit. Pour un produit en évolution, les membres de l'équipe doivent avoir une meilleure compréhension de la situation dans son ensemble. Cela leur permet non seulement de contribuer efficacement, mais aussi d'assumer une plus grande responsabilité. Le résultat est une équipe plus concentrée et adaptative qui a toujours un doigt sur le pouls de ses clients et reconnaît la différence que leurs sprints peuvent faire en contribuant à la vision et au succès éventuel du produit.

Étudiez les cours de gestion de produits en ligne dans les meilleures universités du monde. Gagnez des programmes de maîtrise, Executive PGP ou Advanced Certificate pour accélérer votre carrière.

Programme en vedette pour vous : programme de certification Design Thinking de Duke CE