Gérer 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

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.