Le Scrum Master au service du Product Owner

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 :

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

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 ?

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.

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.