Le Backlog et le Scrum Board

Méthode agile : Présentation générale

Le Backlog rassemble l’ensemble des histoires d’un projet. Cette liste est généralement numérique mais peut être présentée sous forme de postits.

Cette liste est maintenue par le Product Owner avec l’aide du Scrum Master.

Chaque histoire, au sein du Backlog a un label décrivant sa structure ( NFR, Story, Spike…) et des labels d’avancement et de portée. Tous les acteurs du projet peuvent ajouter des histoires au Backlog car il rassemble toutes les sources d’actions du projet (Bug Tracker, User Feedback, retour d’intégration continue, retour éventuel de logs, rapports d’erreurs, discussions entre acteurs…).

À chaque cérémonie, le Product Owner extrait du Backlog un certain nombre d’ histoires et leur spécifie un label d’avancement. Ces histoires extraites forment un sous-Backlog intitulé Sprint Backlog. Le Backlog général, dans ce cas, porte le nom de Product Backlog. Notez qu’on peut hiérarchiser des Backlogs comme on le souhaite afin d’affiner au mieux et de garder de l’efficacité.

Toutes les histoires du Sprint Backlog doivent être estimées par l’équipe et le Poker agile.

Le label de portée peut être défini par n’importe quel acteur du projet qui suit la stratégie de management du projet (membres de l’équipe ou uniquement le Scrum Master par exemple). Il définit aussi un sous-Backlog et permet de faire fonctionner plusieurs équipes en parallèle ou de diriger les histoires vers les membres de l’équipe qui peuvent y répondre le mieux.

Exemples de labels

Labels d’avancement utilisés chez Limawi :

• DISCUSSION : Cette histoire n’a pas encore été étudiée. C’est un nouveau retour d’une source, une nouvelle idée…
• TODO : Cette histoire a été estimée et extraite du Backlog par le Product Owner pour le Sprint backlog en cours. Elle n’a pas encore été commencée par l’équipe.
• DOING : Après TODO, une fois que l’équipe a commencé l’ histoire.
• REVIEW : Après DOING, une fois que l’équipe a estimé avoir fini l’ histoire. Un membre de l’équipe qui n’a pas participé dans cette histoire ou un membre extérieur estime si le développement effectué correspond bien à l’histoire. Il y a souvent un va-et-vient entre DOING et REVIEW pour affiner la correspondance entre l’ histoire et son développement.
• DONE : Après REVIEW, une fois que la personne en charge de la revue a donné un feu vert. L’ histoire est réalisée. La définition du DONE est importante et peut varier suivant les types d’ histoires et la définition initiale donnée en cours de Sprint 0 ou de Discovery & Framing. C’est, en général, le Product Owner qui déplace en DONE.
• POSTPONED : Cette histoire a été mal estimée ou un problème a été rencontré en cours de Sprint. Elle est renvoyée à un Sprint suivant.

Labels de portée :

• SECURITY : Cette histoire a une notion de sécurité. Elle est traitée par les membres spécialisés en sécurité.
• PERFORMANCE : Cette histoire a une notion de performance. Elle est traitée par les membres spécialisés en performances.
• DOC : Cette histoire a une notion de documentation. Elle est traitée par les membres spécialisés en documentation.
• TEST : Cette histoire a une notion de test. Elle est traitée par les membres spécialisés en test.

Scrum Board

Les histoires du Sprint Backlog peuvent être présentées sur un Scrum Board.

C’est un tableau à colonnes. Chaque colonne représente un label d’avancement. Les colonnes sont organisées de gauche à droite selon l’ordre logique des labels d’avancement.

L’idée est de faire avancer les histoires de la gauche (TODO) vers la droite (DONE). Une équipe agile efficace a toutes les histoires en DONE à la fin du Sprint.

Sources

• L’expérience Limawi
• Unow