Backlog

En Scrum, il existe deux backlog, celui du produit et celui du sprint.

Le Product Backlog

Le Product Backlog est une liste ordonnée de tout ce qui pourrait être requis dans le produit et est l’unique source des besoins pour tous les changements à effectuer sur le produit.

Qui gère le Product Backlog?

Le Product Owner est responsable du Product Backlog dans son contenu, sa disponibilité et son ordonnancement. Un Product Backlog n’est jamais complet. Le Product Backlog évolue au fur et à mesure que le produit et le contexte dans lequel il sera utilisé évoluent.

Que contient un Product Backlog?

Le Product Backlog liste toutes les fonctionnalités, besoins, améliorations et correctifs correspondant aux changements devant être appliqués au produit lors de livraisons futures. Les items ou User Stories du Product Backlog incluent une description, un ordre, une estimation de l’effort et de la valeur. Les besoins n’arrêtent jamais de changer, ce qui fait du Product Backlog un document vivant.

Comme un fromage, il doit être affiné.

L’affinage du Product Backlog consiste en l’ajout de détails, d’estimations et de l’ordonnancement des items du Product Backlog. 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 items du Product Backlog. Durant l’affinage du Product Backlog, les items 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 items du Product Backlog peuvent être modifiés à n’importe quel moment par le Product Owner. Les premiers items du Product Backlog sont généralement plus détaillés que les suivants. Leur estimation est plus précise dû à une plus grande clarté et un niveau de détail accru. Les items qui sont placés plus loin dans le Product Backlog sont moins détaillés. Les items qui occuperont l’Équipe de Développement durant le prochain Sprint sont affinés au point que n’importe lequel peut être raisonnablement « Terminé » dans un Sprint. Ces items sont réputés « Prêts » pour leur sélection dans une planification de Sprint. L’Équipe de Développement est responsable de toutes les estimations. Le Product Owner peut influencer l’Équipe de Développement en l’aidant dans sa compréhension et le choix des compromis, mais les personnes qui effectueront le travail ont le mot final sur les estimations. Les « burn-down », les « burnups » sont utilisés afin de prévoir la progression des sprints.

Séance d’affinage avec l’équipe Scrum

Sprint Backlog

Le Sprint Backlog est l’ensemble des users stories sélectionnées pour le Sprint plus un plan pour livrer l’incrément du produit et réaliser l’objectif du Sprint.

Qui gère le Sprint Backlog?

Le Sprint Backlog est une prévision que l’Équipe de Développement fait de la fonctionnalité qui sera présente dans le prochain incrément et le travail nécessaire pour livrer cette fonctionnalité dans un incrément « terminé ». Le Sprint Backlog rend visible tout le travail que l’Équipe de Développement identifie comme nécessaire pour atteindre l’objectif du Sprint. Lorsque le travail est effectué ou complété, les estimations du travail restant sont mises à jour. Seule l’Équipe de Développement peut changer son Sprint Backlog durant un Sprint.

Représentation d’un Sprint Backlog

Le Sprint Backlog est une vue en temps-réel et très visible du travail que l’Équipe planifie d’accomplir durant le Sprint et il appartient uniquement à l’Équipe de Développement. Il est souvent représenter comme quatre colonnes, une colonne user stories, une colonne TODO, une colonne DOING, une colonne DONE. Sur internet, on lui donne aussi le nom de Scrumboard. 

Si vous voulez un outil qui créé et gère votre Product Backlog et vos Sprint Backlogs, je ne peux que vous conseiller Taïga.io.