Cas pratique autour de la création d’un Product Goal

Product Goal : qu’est-ce que c’est ?

Le dernier Scrum Guide sorti en novembre 2020 a amené une nouvelle notion, l’Objectif de Produit (Product Goal). On peut y lire :

L’Objectif de Produit décrit un état futur du produit qui peut servir de cible à la Scrum Team pour planifier. L’Objectif de Produit est dans le Product Backlog. Le reste du Product Backlog émerge pour définir « ce qui » permettra d’atteindre l’Objectif de Produit.

L’Objectif de Produit est l’objectif à long terme de la Scrum Team. Ils doivent atteindre (ou abandonner) un objectif avant de s’attaquer au suivant.

Je constatais par le passé que les équipes Scrum enchaînaient les Sprints, les uns après les autres, avec dans le meilleur des cas un Sprint Goal pour chaque Sprint. Souvent, lors d’un Sprint on allait dans un sens, le Sprint suivant on allait dans un autre sens et il était donc difficile de comprendre la stratégie vers laquelle s’en allait le produit. On développait “pour développer” sans vraiment tenir compte de l’objectif d’affaire que l’on désirait atteindre.

Depuis que la notion de Product Goal est présente, il y a plus de clarté sur la direction qui est prise et il est moins nécessaire de justifier des choix à chaque Sprint, vu que la direction générale est connue. Cela n’empêche pas qu’il y ait des exceptions, comme, par exemple, un Sprint consacré à se mettre en conformité avec la RGPD qui n’a rien à voir avec le Product Goal. C’est la vie d’un produit et nous sommes parfois contraints de faire des exceptions.

Ce concept amène donc plus de focus pour la Scrum Team et également plus de transparence auprès des parties prenantes. 

Comment créer un Product Goal ?

Le brouillon initial

Le Product Goal ne sort pas d’un chapeau et devrait s’aligner avec la stratégie d’entreprise et la vision du produit, le Product Goal étant le premier pas stratégique pour permettre d’atteindre la vision du produit.

On peut illustrer cela avec un cas concret vécu avec un Product Owner que j’accompagne. Son produit est un site web public et après discussion avec les parties prenantes, le Product Goal envisagé était :

Marque et visibilité, cohérence visuelle et technique

Cela signifiait en résumé pour le Product Owner que les éléments qui allaient être développés durant les prochains Sprints seraient :

• Mise à jour visuelle de toutes les pages du site web pour se conformer au nouveau Branding
• Mise à jour technique de toutes les pages du site web pour se conformer à la nouvelle manière technique de développer les pages.

Intéressant, non ? On obtient ainsi une direction et le Product Backlog peut être construit à partir du Product Goal.

Pourtant, je n’étais pas satisfaite de ce Product Goal… j’avais le sentiment qu’il était “plat”.

Des questions

Du coup, je me suis aidée de quelques questions, tirées de la formation Professional Scrum Product Owner, pour valider si le Product Goal était bien percutant. 

Notre Product Goal vous enthousiasme-t-il, vous et vos clients, par les possibilités qu’il offre ?   Ma réponse serait “Mouais…”

Pouvons-nous utiliser le Product Goal pour éviter d’augmenter les risques ou de perdre du temps et de l’argent ?   Ma réponse serait “Mouais…”

Compte tenu du Product Goal, qu’est-ce qui indiquerait que vous devriez l’abandonner ?    Nous n’avons pas vraiment cette indication. Quand avons-nous atteint la bonne cohérence visuelle et technique ?  Qu’est-ce que cela signifie exactement ?

Lorsque nous atteindrons ce Product Goal, qu’est-ce qui aura clairement changé ou été amélioré du point de vue des clients ?  Ce n’est pas très clair, nous aurons plus de cohérence, mais à nouveau qu’est-ce que cela signifie ? On peut être cohérent dans la médiocrité (écran visuellement incompréhensible, code redondant…)

Et j’ai donc eu ma confirmation qu’il y avait quelque chose qui clochait au niveau de la formulation de ce Product Goal. Mais quoi ?

L’impact !

Au final, le plus important, c’est de comprendre “Pourquoi on le fait ? Quel est l’impact que l’on désire avoir ?”, de comprendre ce qui motive de dépenser de l’énergie, du temps et de l’argent pour aller dans une certaine direction.

Peut-être que vous aurez envie de me rétorquer “tu joues sur les mots, c’est bon, on a compris pourquoi” et pourtant, si vous faites l’exercice, vous vous rendrez compte que ça fait toute la différence. Ca fait toute la différence en termes de compréhension et transparence envers toutes les personnes qui s’intéressent au produit et également en terme de motivation pour atteindre cet objectif.

Si je dis “Je pose des briques” ou “Je construis le mur du nouvel hôpital pour enfant”, comment ces deux phrases résonnent pour vous ? Cela fait-il une différence ?

J’ai donc continué à réfléchir autour de la proposition du Product Goal “Marque et visibilité, cohérence visuelle et technique” en me demandant : quel est l’impact que l’on désire avoir ici sur les utilisateurs ? sur les développeurs ? pour les sponsors ?

Dans la liste des idées qui ont émergées, il y a en vrac :

• Faciliter l’utilisation du site
• Faciliter les développements à venir
• Rendre reconnaissable en un coup d’œil de quel site il s’agit
• Augmenter le temps passé par les utilisateurs sur les pages offrant du contenu
• Diminuer le temps passé par les utilisateurs à rechercher de l’information sur le site
• Diminuer le temps de tests des développeurs entre l’ancien et le nouveau design

Après discussion avec le Product Owner, nous en sommes arrivés au Product Goal :

Faciliter l’utilisation du site web par les utilisateurs en le rendant visuellement consistant et faciliter les développements en le rendant techniquement consistant.
Amener plus de cohérence aux utilisateurs en leur offrant un contenu plus adapté et intéressant.

Nous avons donc ici un impact plus clair qui est :

• Faciliter l’utilisation du site
• Faciliter les développements

et comment on va atteindre cela :

• Consistance visuelle
• Consistance technique

Et on reprend les questions

Si on se pose à nouveau les questions avec ce nouveau Sprint Goal, qu’est-ce que ça donne ?

Notre Product Goal vous enthousiasme-t-il, vous et vos clients, par les possibilités qu’il offre ?     Ce n’est pas non plus un waouh, mais je comprends l’impact et du coup cela me motive.

Pouvons-nous utiliser le Product Goal pour éviter d’augmenter les risques ou de perdre du temps et de l’argent ?    Clairement oui. Pour la partie technique cela est évident, car nous allons faciliter les développements ce qui veut dire moins de bugs et moins de temps de développement.

Compte tenu du Product Goal, qu’est-ce qui indiquerait que vous devriez l’abandonner ?     Nous ne savons toujours pas vraiment de quelle manière nous saurons que nous aurons atteint notre objectif.

Lorsque nous atteindrons ce Product Goal, qu’est-ce qui aura clairement changé ou été amélioré du point de vue des clients ?    Encore une fois, l’impact est plus clair, par contre, nous n’avons pas de chiffres ou de données tangibles pour valider l’impact.

Ce Product Goal est plus clair et mieux formulé que le précédent. Il y aurait sûrement matière à l’améliorer encore, mais nous allons nous en satisfaire.

Product Goal Canvas

Nous avons ensuite décidé d’utiliser le Product Goal Canvas mis à disposition par Ralph Jocham afin de pouvoir réfléchir aux différents paramètres intéressants autour du Product Goal. En remplissant ce canevas, le Product Goal devient concret et ne se résume pas à une phrase “pour faire bien” ou “parce que Scrum dit qu’on doit avoir un Product Goal”.

Sans rentrer dans le détail du canevas (je vous invite à lire la page web dédiée), je vais m’arrêter un peu sur la section “Valuable Outcome and Measures” qui permet de répondre aux questions laissées en suspens dans la section ci-dessus. Je constate que nous avons souvent tendance à oublier que pour vérifier que nous sommes dans la bonne direction, il nous faut mesurer les résultats, l’impact qu’on a eu. Est-ce que nos hypothèses étaient les bonnes ? Est-ce que l’impact attendu est bien avéré ? Quand doit-on s’arrêter ?

On constate alors à quel point il peut être compliqué de trouver les bonnes métriques et les données associées.

Dans notre cas pratique, nous avons mis en évidence les métriques suivantes.

Market / End User – Leading  Ce cadran indique notre capacité à innover. Il s’agit de métriques que nous pouvons mesurer avant d’avoir atteint notre Product Goal et qui ont un impact direct sur l’utilisateur final.Dans notre cas, nous mesurons le temps de chargement de nos pages web. Nous avons également fixé un seuil maximal que nous ne devons pas dépasser.

Internal Capabilities – Leading  Ce cadran se concentre sur le temps de mise sur le marché, ce sont des métriques sur notre amélioration continue en interne.Nous avons fait l’hypothèse que le temps de développement aujourd’hui est plus long que ce qu’il sera à l’avenir où tout le code sera migré vers les nouveaux templates. Nous mesurons en conséquence le Cycle Time, à savoir le temps entre le moment où on commence à travailler sur une tâche jusqu’au moment où elle est considérée comme terminé.Nous allons également tout simplement mesurer le nombre de pages publiés avec l’ancien template. Au fur et à mesure des sprints, ce nombre devrait être en diminution.

Market / End User – Lagging  Ce cadran se concentre sur la valeur qui n’a pas encore été réalisée, les métriques que nous avons ici doivent nous permettre de dire quand notre Product Goal est atteint avec succès.Dans notre situation, cette métrique nous a semblé la plus compliquée à trouver et mettre en place. Le site web étant un site web public, il faudrait un panel d’utilisateurs à sonder par exemple ou encore mettre un sondage en ligne sur le site au risque de recevoir de mauvaises notes car ces demandes sont mal perçues.Nous avons opté finalement pour définir un panel à l’interne de l’entreprise qui ne travaille pas directement avec le site web pour récolter des informations.Nous avons défini que si nous ne recevons pas de commentaires pointant :un manque d’identité visuelun style patchworkamateurismevieux stylecela serait considéré comme un succès.Nous allons sonder notre panel une première fois avant les modifications et nous comptons sonder un autre panel dans quelques semaines lorsque nous penserons avoir atteint le Product Goal.

Internal Capabilities – Lagging  Ce cadran se concentre sur la valeur actuelle (déjà livrée). La métrique doit nous permettre de dire à l’interne que l’objectif a bien été atteint.Lorsqu’il sera possible de supprimer l’ancien code complètement de notre solution informatique, cela voudra dire que le Product Goal est bien atteint d’un point de vue interne.Nous avons aussi désiré suivre d’autres métriques autour du site web tels que le nombre d’utilisateurs qui reviennent et le temps que passe un utilisateur sur le site. Il nous semble intéressant de suivre ces métriques, même si nous ne sommes pas sûrs aujourd’hui de pouvoir en tirer un lien de cause à effet : comment savoir si les modifications effectuées ont vraiment impactées le nombre de fois où un utilisateur revient sur le site ? Pourquoi ne serait-ce pas plutôt la campagne publicitaire XYZ qui aurait cet impact ? Il est compliqué de répondre à cela.

Conclusion

Nous avons à présent un Product Goal écrit de telle manière à ce que l’impact que l’on désire obtenir soit au centre de la formulation. Nous avons également des métriques qui vont nous permettre de suivre l’avancement vers l’objectif et si celui-ci est atteint. Ces métriques sont d’ailleurs montrées chaque deux sprints lors des Sprint Review afin de présenter à nos parties prenantes l’avancement et pouvoir générer des discussions et des feedbacks. C’est aussi une manière de leur montrer en quoi ce Product Goal est générateur de valeur à la fois à l’externe et en interne.

C’est la première fois que nous mettons en place tout cela. Au sein de l’équipe Scrum, cela nous semble utile et nous espérons que les résultats dans quelques mois nous montrent que cela en valait la peine et que l’objectif sera vraiment un succès. À ce propos, le plus gros risque que nous avons mis dans notre Product Goal Canvas est de devoir changer de Product Goal avant d’avoir réussi à l’atteindre.