Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Scrum Master
  3. Le Scrum Master au service du Product Owner
Extrait - Scrum Master Préparation à la certification Professional Scrum Master (examens PSM I et PSM II)
Extraits du livre
Scrum Master Préparation à la certification Professional Scrum Master (examens PSM I et PSM II)
1 avis
Revenir à la page d'achat du livre

Le Scrum Master au service du Product Owner

Prérequis et objectifs

1. Prérequis

Maîtriser les quatre premiers chapitres.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Comprendre le rôle de Product Owner.

L’aider à identifier et clarifier les objectifs du produit.

L’aider à planifier l’activité.

L’aider à créer et affiner le Backlog de produit.

Introduction

Le guide Scrum dresse une liste non exhaustive des actions que le Scrum Master peut mener pour servir au mieux le Product Owner :

  • S’assurer que les objectifs, l’étendue et le domaine du produit sont compris par tous les membres de l’équipe Scrum de la meilleure manière possible.

  • Trouver des techniques pour une gestion efficace du Backlog de produit.

  • Aider l’équipe Scrum à comprendre le besoin des éléments, clairs et concis, du Backlog de produit.

  • Comprendre la planification de produits dans un contexte empirique.

  • S’assurer que le Product Owner sait comment organiser le Backlog de produit pour maximiser la valeur. 

  • Comprendre et mettre en œuvre l’agilité.

  • Faciliter les évènements Scrum en cas de demande ou de nécessité.

Pour servir au mieux le Product Owner, le Scrum Master doit savoir quel est son rôle, son périmètre de responsabilité et d’action, sa position dans l’entreprise et son rapport avec les autres acteurs du projet, qu’ils soient internes ou externes à l’équipe Scrum.

Les responsabilités du Product Owner

Dans les premières versions de Scrum, Jeff Sutherland décrivait le rôle du Product Owner de cette manière :

« Le Product Owner est responsable de maximiser le retour sur investissement (ROI) en identifiant les caractéristiques du produit, en les traduisant en une liste d’éléments priorisés, en décidant lesquels devraient figurer en haut de la liste pour le prochain Sprint, et en continuant de prioriser et d’affiner la liste. Le Product Owner est responsable des pertes et profits pour le produit, en supposant qu’il s’agisse d’un produit commercial. »

Scrum Papers page 15

La version 2017 du guide Scrum présente ce rôle avec un prisme de lecture plus large :

Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement.

Guide Scrum 2017

La notion de retour sur investissement est très claire et parfaitement mesurable, mais étant réservée à des produits commerciaux, elle a été remplacée par celle de « valeur produit ». En revanche, dès lors que le produit présente au moins un aspect commercial, cette notion de retour sur investissement doit être considérée comme un objectif du projet, ou à défaut...

Focus sur les objectifs

Le Scrum Master doit s’assurer que les objectifs, l’étendue et le domaine du produit sont compris par tous les membres de l’équipe Scrum de la meilleure manière possible. Pour en avoir l’assurance, une des meilleures méthodes consiste à demander au Product Owner d’indiquer quelle est sa vision des objectifs, puis d’aller poser la même question à quelques membres de l’équipe et quelques parties prenantes clés, par exemple le sponsor du projet. Le moindre écart démontre que les objectifs ne sont pas compris par tout le monde. C’est une bonne manière de s’assurer de la transparence des objectifs. Lorsque l’objectif est commercial, il est facile de le mesurer clairement en euros, mais certains objectifs sont plus complexes à mesurer de manière claire et compréhensible par tous.

« L’objectif est de réaliser une refonte globale de l’intranet de la compagnie avant la fin de l’année prochaine » n’est pas un objectif clair. Il n’est pas mesurable, ne s’appuie sur aucune raison valable et ne permet pas de répondre à l’évidente question du pourquoi. Dans ce contexte, poser à chaque membre de l’équipe la question « pourquoi travailles-tu sur ce projet ? » produira autant de réponses divergentes que l’équipe comporte de membres. Ce n’est pas une équipe qui travaille, mais un ensemble d’individus, chacun à sa façon et chacun allant dans son sens.

Mais concrètement, qu’est-ce qu’un objectif ?

1. Définition du terme objectif

Un objectif est un indicateur quantifié que l’on cherche à atteindre ou dépasser. Contrairement à un but ou à une contrainte, un objectif peut être partiellement atteint, ou dépassé, et cette différence doit être mesurable, tant au niveau de l’objectif lui-même que des résultats attendus.

L’acronyme mnémotechnique SMART permet d’aider le Product Owner à bien qualifier les objectifs de son produit :

  • Spécifique : simple et clair à comprendre. Ne faisant pas doublon avec un autre....

Le plan de release

Le Scrum Master au service du Product Owner doit « comprendre la planification de produit dans un contexte empirique » et « s’assurer que le Product Owner sait comment organiser le Backlog de produit pour maximiser la valeur ». Ces deux conditions nécessitent de maîtriser des techniques d’organisation du produit dans le temps. L’agilité consiste à s’adapter aux exigences du moment présent plutôt que de planifier finement une activité longtemps à l’avance. Cela ne signifie pas que le Product Owner avance « à vue », bien au contraire. Il doit avoir une vision, une stratégie, savoir parfaitement où il conduit l’équipe de développement et pourquoi.

Plutôt que de décrire finement au travers de dossiers de conceptions fonctionnelles le quoi et le comment, il se concentre sur le pourquoi, envisage avec ses équipes les meilleurs moyens d’atteindre les objectifs lors de séances de travail collaboratives (planification de Sprint et affinage du Backlog de produit) et leur délègue totalement le comment.

Tout comme le Backlog de Produit, le plan de release du Product Owner est un artefact vivant qui doit évoluer tout au long du développement du produit. Il peut être remis en cause en profondeur en fonction de la manière dont le produit avance, mais également en fonction de la manière dont il est utilisé ou perçu par des personnes à qui il est destiné.

À partir d’un référentiel d’exigences, il est plus facile d’identifier les objectifs essentiels d’un produit, les objectifs hérités (ou objectifs de support) qui, lorsqu’ils sont atteints, permettent d’atteindre l’objectif parent, et les moyens envisagés. Le Product Owner peut alors déterminer la quantité de Sprints qu’il peut raisonnablement consacrer à tel ou tel objectif, en fonction de la durée totale allouée...

La clarté des éléments du Backlog de produit

La plupart des équipes Scrum utilisent le format des user stories pour décrire les éléments du Backlog de produit, et c’est une bonne pratique. Hélas, de nombreuses personnes imposent ce formalisme sans savoir pourquoi elles le font. Bien souvent, face à cette question leur réponse est invariablement : « parce que c’est écrit dans le guide Scrum ». Non seulement ce n’est pas écrit, mais le terme même user story n’y figure pas. Le guide Scrum stipule des « items », des éléments.

Ce que le guide Scrum recommande est que ces éléments soient clairs et compréhensibles, et il stipule, dans les rôles du Scrum Master auprès du Product Owner, qu’il doit « Aider l’équipe Scrum à comprendre le besoin des éléments clairs et concis du Backlog de produit. »

Le formalisme d’écriture imposé par les user stories garantit que les éléments restent concis, mais absolument pas qu’ils soient clairs. À tel point que Jeff Patton a mis en place une technique permettant de redonner de la clarté à un ensemble d’user stories qui, prises individuellement, faisaient perdre de vue la vision produit : « User Story Mapping » ou cartographie des récits utilisateurs.

La priorité pour le Scrum Master est bien de comprendre pourquoi il est préférable de procéder d’une manière particulière. Si une équipe novice dans l’agilité décide de formaliser les éléments du Backlog de produit d’une manière claire et concise et que le Scrum Master impose de réécrire chaque élément en respectant le formalisme des user stories, cela constitue non seulement une perte de temps pour le Product Owner, mais c’est également un risque potentiel de perte de vélocité et enfin il s’agit d’une démarche autoritaire qui s’inscrit à l’opposé de tous les principes agiles. Non seulement le Scrum Master se pose en dictateur d’une méthode ce qui est contraire à son rôle de serviteur...

Affiner le Backlog de produit

Le Scrum Master au service du Product Owner doit également « trouver des techniques pour une gestion efficace du Backlog de produit » et la meilleure manière d’y arriver consiste à ce que chaque membre de l’équipe ait la vision la plus complète possible des éléments qui doivent être produits dans les Sprints à venir.

Si nous nous référons au principe des itérations défini par Scrum (Introduction), cette pratique doit permettre au Product Owner de transmettre à l’équipe une opportunité identifiée, ou un besoin formalisé, par exemple sous forme d’une exigence, et il revient à cette dernière de comprendre le besoin et d’évaluer des solutions.

images/img-016.png

Pour cela, certaines équipes arrêtent leurs travaux quelques heures et se réunissent toutes ensemble pour affiner les éléments des Sprints à venir. C’est une excellente manière d’y voir clair et de respecter le délai (time-box) du prochain sprint planning, mais ce n’est pas la meilleure démarche pour maximiser la valeur du travail de l’équipe de développement.

La littérature Scrum évoque les termes d’affinage, de nettoyage ou de toilettage.

1. Qu’est-ce que l’affinage du Backlog de produit ?

Le guide Scrum consacre deux paragraphes complets à cette activité :

L’affinage du Backlog de produit (Backlog de produit Refinement) consiste en l’ajout de détails, d’estimations et de l’ordonnancement des éléments du Backlog de produit. Il s’agit d’une activité régulière dans laquelle le Product Owner et l’équipe de développement collaborent pour détailler les éléments du Backlog de produit. Durant l’affinage du Backlog de produit, les éléments sont revisités et révisés. L’équipe Scrum décide comment et quand l’affinage est effectué. L’affinage n’occupe généralement pas plus de 10 % de la capacité de l’équipe de développement. Toutefois, les éléments du Backlog de produit...

Validation des acquis : questions/réponses

Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-après.

1. Questions

1 Le Scrum Master aide le Product Owner à rendre transparents de nombreux éléments. Quel est le premier élément à clarifier ?

2 Que signifie SMART ?

3 Par quels moyens le Scrum Master peut-il aider le Product Owner à identifier clairement la valeur du produit ?

4 Comment le pouvoir et l’autorité du Product Owner sur le produit peuvent-ils être renforcés ?

5 Citez un bénéfice induit par l’identification d’objectifs clairs.

6 Qu’est-ce qu’un référentiel d’exigences permet d’identifier ?

7 Quel est le changement majeur induit par l’agilité sur la planification de l’activité ?

8 À quel moment le Product Owner peut-il modifier son Backlog de produit ?

9 À quel moment le Product Owner peut-il modifier son plan de release ?

10 Quelle matrice le Product Owner doit-il utiliser pour organiser son Backlog de produit ?

11 Que signifie la règle des 3C appliquée aux user stories ?

12 Concernant les éléments du Backlog de produit, le plus important est qu’ils soient......... Veuillez compléter la phrase.

13 Qui peut annuler un Sprint ?

14 Combien de temps peut passer l’équipe Scrum à affiner le Backlog de produit ?

15 Quelles sont les deux activités pratiquées lors de l’affinage du Backlog de produit ?

16 Que doit faire en priorités le Product Owner lorsqu’il présente un nouvel élément de son Backlog de produit à l’équipe de développement ?

17 Quel est le meilleur moyen de s’assurer que l’on est compris ?

18 Quelle pratique le Scrum Master peut-il conseiller à l’équipe pour formaliser les processus de reformulation ?

19 De quelle manière...