Gérer le Backlog de produit

Organiser le Backlog de produit

Le chapitre De la stratégie au plan opérationnel décrit le Backlog de produit comme un référentiel ayant pour vocation d’organiser, de planifier et de communiquer :

Le Backlog produit est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit. Guide Scrum 2020

Ce même chapitre décrit également comment la vision du produit est progressivement traduite en une stratégie et un plan opérationnel. Tout cela doit contribuer à planifier des actions dont le Backlog de produit doit refléter l’organisation. En ce sens, c’est donc un outil de communication.

Il ne s’agit pas de trier en fonction de l’urgence ou d’une priorité reposant sur une règle, mais bien d’organiser les éléments constituant le Backlog selon la stratégie établie.

Pour mieux comprendre l’organisation du Backlog, imaginez une liste de courses que l’on rédige avant d’aller réellement au supermarché. Il y a autant de manières de le faire que de ménages, et parfois deux manières différentes existent au sein du même ménage. Vous pouvez écrire les articles les uns après les autres en fonction des idées qui surviennent ou bien de ce que vous avez envie de manger. Il est possible de commencer par les promotions sur les prospectus, puis de compléter par les éléments pouvant s’accommoder avec ces premiers choix. Vous pouvez écrire en commençant par ce qui manque le plus et en terminant par les éléments les moins utiles, ou bien en fonction de la disposition des rayons dans le supermarché pour optimiser votre parcours. C’est votre organisation selon votre stratégie et votre vision des courses. Si vous revenez à la maison avec des articles qui ne sont pas sur votre liste, ce n’est pas forcément un signe d’agilité. En revanche, si vous vous rendez compte que vous avez oublié des articles, c’est que vous avez assurément besoin d’inspecter vos processus lors d’une rétrospective.

Cette simple organisation montre immédiatement au Product Owner les éventuelles défaillances...

Affiner le Backlog de produit

1. Rappel du principe itératif

Le cycle itératif prescrit par le mouvement agile implique que le produit ne soit pas intégralement conçu initialement, mais que son périmètre puisse profondément évoluer durant la conception et la réalisation du produit.

Ce cycle est répété tout au long de la réalisation du produit, et dans certains cas tout au long de la vie du produit. Par exemple, Facebook évolue en permanence alors que le produit est utilisé par des milliards de personnes.

Ce cycle se retrouve également au travers des liens entre les artefacts de Scrum : le Backlog de produit permet de construire le Backlog de Sprint, qui délivre un incrément, qui recueille de nouveaux besoins, qui seront inscrits dans le Backlog de produit, etc.

Mais lorsqu’un nouveau besoin arrive dans le Backlog de produit, il est grossier, plus ou moins volumineux et complexe à réaliser. Il peut exister plusieurs moyens d’y répondre, plusieurs solutions et, dans certains cas, personne n’a jamais envisagé ce type de problème. Il n’y a pas de référentiel sur lequel s’appuyer.

Lorsque les téléphones mobiles permettant de consulter Internet sont apparus, il a été nécessaire d’adapter rapidement les contenus des sites web pour les rendre lisibles sur ce nouveau support. Demain, il faudra peut-être concevoir de nouvelles interfaces basées sur des échanges vocaux plutôt que visuels.

Les besoins, les objectifs ou les exigences initialement identifiés ou découverts à mesure que l’incrément du produit est mis à disposition des utilisateurs sont tous traités de la même manière : ils sont progressivement affinés au lieu d’être spécifiés en détail en amont de la réalisation du produit.

2. Définition de l’affinage

L’affinage du Backlog de produit 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...

Faire face aux changements

Le Product Owner a beau avoir pu consacrer beaucoup de temps à organiser et à affiner son Backlog de produit par rapport à sa vision du produit à un instant précis, la situation ne sera jamais figée et évoluera forcément. Plusieurs changements vont impacter l’organisation du Backlog de produit à mesure que le produit est réalisé, mais également des fluctuations technologiques, culturelles, d’usage ou de marché.

1. Gérer les nouvelles demandes

Scrum est un cadre de travail agile, et le manifeste agile considère qu’une nouvelle demande, même lorsqu’elle survient lors de la réalisation d’un produit, n’est pas une dérive ou un risque mais une opportunité.

« Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client. »

Mais cela ne signifie pas qu’il faut accepter tout et n’importe quoi sous prétexte qu’il faut être agile. Les nouvelles demandes doivent avoir un rapport avec le produit, aller dans le bon sens et apporter de la valeur. Dans le cas contraire, elles doivent être rejetées.

Si une partie prenante demande au Product Owner d’assouplir les contrôles de sécurité parce que cela gêne les utilisateurs, alors que le produit est soumis à de fortes contraintes de sécurisation, cette demande doit être fermement refusée, tout en conservant une attitude positive et ouverte.

a. Être proactif

C’est bien connu, lorsqu’on attend des informations, elles arrivent toujours au dernier moment. Ainsi, si le Product Owner attend que les parties prenantes lui fassent spontanément part de leurs remarques, ces dernières arriveront en plein milieu du dernier Sprint de la release et seront évidemment urgentes et prioritaires.

Il est possible de blâmer les parties prenantes pour leur manque d’organisation et de réactivité, et c’est certainement la réalité, mais ce processus peut se répéter à l’infini sans que des changements structurels durables apparaissent.

Le Product Owner dispose de nombreuses occasions de recueillir...