Le product backlog dans un projet Scrum

Aujourd’hui, nous vous parlons de l’importance du Product Backlog dans un projet Scrum. Sous la responsabilité du Product Owner, il va permettre de planifier les sprints et de prioriser les attentes et les besoins du client.

Le Product Backlog est le point central de tout projet Scrum. Il est sous la responsabilité unique du Product Owner, mais doit également être accessible par l’équipe. C’est à partir de ce document que les sprints seront planifiés. Mais que contient-il vraiment et comment le rédiger ?

La liste des items du product backlog

Vous avez sans doute déjà rencontré le terme de “users stories”, notamment si vous avez une expérience avec d’autres méthodes agiles. Dans Scrum, ces users stories sont appelés items. Chaque item est une exigence du client rédigé selon une terminologie métier et non technique.

Il appartient au Product Owner de s’assurer que l’item pourra être compris par l’équipe. Le Product Owner créera donc cette liste avec le client et les utilisateurs de l’application. Après s’être assuré qu’il n’y a pas de doublons ou d’items qui se chevauchent, le Product Owner pourra attribuer un ID à chaque item et les disposer dans un tableau avant de procéder à un premier classement.

L’importance des items dans le product backlog

À ce stade, le Product Owner va attribuer une valeur d’importance à chaque item. Cette valeur représentera l’attente du client et son besoin de chaque fonctionnalité. Il est fréquent de voir le terme priorité être utilisé à la place d’importance. Il est toutefois recommandé de l’éviter car la priorité exclut totalement certaines notions, comme la dépendance entre les items.

Cette valeur d’importance n’est pas figée et elle évoluera au fur et à mesure des feedbacks utilisateurs. Il est important de noter que seul le Product Owner est en droit d’attribuer ou modifier cette valeur.

L’estimation initiale

L’estimation initiale représente la quantité de travail nécessaire au développement de l’item déterminée par l’équipe elle-même. Elle prend en compte le temps de développement et la complexité de celui-ci. Il ne s’agit ici que d’une estimation qui, par définition, ne peut pas être exacte. Pour éviter toute mauvaise interprétation, il est courant d’utiliser une valeur étalon et non une valeur temporelle. Très souvent, l’estimation est faite grâce à la méthode du Planning Poker. C’est une technique ludique qui propose à chaque membre de l’équipe d’attribuer une valeur comprise dans la suite de Fibonacci sans avoir connaissance de la réponse des autres membres. Les réponses sont ensuite dévoilées en même temps afin d’encourager les discussions et échanges d’opinion sur la complexité de l’item en question. Cela permet finalement d’aboutir à l’estimation la plus juste possible.

Démonstration et notes

La colonne démonstration indique la démarche à suivre pour présenter l’item lors de la réunion de fin d’itération. Elle peut également faciliter la conception des tests par le Product Owner et donc servir de référence quant à l’acceptation ou non de l’item développé durant l’itération. Vous trouverez sans doute des Product Backlogs dans lesquels cette section sera absente, mais elle est fréquemment utilisée. Il en va de même pour la colonne note. Bien que très générique, elle permet souvent d’indiquer de manière très succincte les dépendances et autres informations pouvant influer sur l’importance et le développement de l’item.

En complément

Les Product Backlogs de chaque projet diffèrent en fonction des besoins spécifiques de ceux-ci. Néanmoins, les éléments donnés ici sont, de loin, les plus utilisés et certains d’entre eux sont même indispensables. Le guide Scrum préconise un maximum de 150 items dans un backlog : au-delà de ce nombre, certains items auront été détaillés de manière anticipée et pourront être la source d’une perte d’efficacité dans la mise en place de Scrum.