Les backlogs de Scrum

Le backlog est un élément clé dans le processus Scrum. Mais il y a plusieurs backlogs...

La notion de backlog n'est pas très difficile à comprendre : c'est une liste dont les éléments sont rangés par priorité. Mais le fait qu'il y ait plusieurs backlogs peut induire une confusion dans la compréhension de Scrum. L'article du JDNet dont je parle dans un billet récent parle de 3 backlogs : un backlog de produit, un backlog de release et un backlog de sprint. C'est une mauvaise interprétation, il n'y a en réalité que 2 backlogs[1] dans Scrum.

Backlog de produit

C'est le vrai backlog, le seul qu'on devrait appeler comme ça[2]. Il y en a un seul pour un produit, qui peut avoir une durée de vie égale à celle du produit[3]. Dans ce backlog de produit on trouve les fonctionnalités du produit, souvent représentées par des histoires d'utilisateur. Il est essentiellement bâti par le directeur de produit.

Backlog de sprint

C'est une mauvaise idée des concepteurs de Scrum de l'avoir aussi appelé backlog. C'est également une liste, mais qui contient les tâches à réaliser par l'équipe pendant un sprint. C'est en fait un plan d'itération, on devrait l'appeler plan de sprint. Sa durée de vie est celle du sprint[4]. A chaque nouveau sprint correspond un nouveau backlog de sprint. Il est élaboré lors de la réunion de planification en début de sprint et destiné à l'équipe.

Relation entre le backlog de produit et un backlog de sprint

Pour un sprint on sélectionne les éléments du backlog de produit. La réalisation d'un élément du backlog de produit nécessite du travail. Ce travail est décomposé en tâches qui sont les éléments du backlog de sprint. Donc à un élément du backlog de produit vont correspondre, en général, plusieurs tâches.

Produits dérivés

  • le backlog de produit permet de produire le planning de release[5], c'est à dire le sous-ensemble des éléments du backlog qu'on estime finir pour la date prévue de release.
  • le backlog de produit permet de produire le burndown chart de release, qui est un graphe, mis à jour à la fin de chaque sprint, montrant la tendance de l'avancement dans la réalisation des éléments du backlog de produit
  • le backlog de sprint permet de produit le burndown chart de sprint, qui est un graphe, mis à jour tous les jours, montrant la tendance de l'avancement dans la réalisation des tâches du backlog de sprint.

Notes

[1] plus exactement 2 types de backlogs

[2] j'utilise aussi référentiel des exigences pour parler de la même chose dans un contexte non Scrum

[3] qui peut être longue : le même backlog sert au premier développement puis à tous ceux qui suivent

[4] le backlog du sprint n n'est plus utilisé après la fin du sprint n

[5] cela explique probablement la confusion faite dans l'article du JDNet

Commentaires

1. Le jeudi 08 février 2007, 10:31 par Camille bloch

Il est vrai que d'avoir 2 backlog est source de confusion.

Dans notre équipe, certains ont mit du temps à faire la distinction entre les deux.

Et nous n'en avons pas encore aprlé aux personnes externes à l'équipe...

2. Le jeudi 08 février 2007, 13:39 par Avangel

Je ne suis pas trop d'accord avec le terme "Plan de sprint", en ce sens qu'un "plan" est inscrit dans l'esprit des gens comme une "route à suivre". J'ai eu l'occasion d'en discuter hier avec un spécialiste en facteurs humains, c'est un pattern connu : une fois que l'on a établi mentalement un plan d'action dans un avenir plus ou moins proche, il est très difficile de le remettre en cause.

J'associe personnellement au "backlog" l'idée du changement, d'une certaine façon un "non-ordre" (dans le sens de l'évolution de l'ordre, pas du fouillis), alors qu'un plan est comme une procédure. C'est pour ça que je suis assez partisant de ce terme difficilement traduisible. Ne pas le traduire permet d'y associer un concept différent de ceux qu'on connaît habituellement.

3. Le jeudi 08 février 2007, 18:59 par claude aubry

Bonsoir Avangel. C'est vrai que plan est perçu habituellement dans un sens ne convient pas dans ce contexte, on pourrait croire qu'il faut faire un Gantt. Mais on a vu qu'employer backlog pour le sprint peut induire une confusion avec le backlog de produit. Pourquoi ne pas dire simplement la liste des tâches du sprint ?

4. Le jeudi 08 février 2007, 22:10 par JC

Effectivement les termes prêtent à confusion …

Il est étonnant que Ken Schwaber ou Jeff Sutherland par exemple n’aient pas souhaité lever cette possible ambiguïté.
Le processus Unifié a quant à lui des concepts équivalents sous une terminologie différente, mais peut être plus claire (quoique plan de phase / plan d'itération peut poser pb !).
- Le Backlog produit correspond à peu prés à la « Liste des exigences » fonctionnelles ou non (c'est-à-dire ergonomiques, performance, sécurité...) et représentées ou non sous forme de cas d’utilisation.
- Le "backlog de sprint" correspond simplement au plan d’itération, bien apprécié chez nous (nous n'avons pas ressenti à ma connaissance le problème potentiel évoqué par Avangel).
A ce propos, je viens de publier sur mon blog, Qualitystreet.fr, un rapide parallèle entre UP et SCRUM dans notre contexte, sachant qu'UP tourne déjà depuis plus d'un an. Voici le lien :
www.qualitystreet.fr/?200...

5. Le vendredi 09 février 2007, 22:33 par claude aubry

Dans le RUP il n'y a pas cette notion de référentiel unique pour les exigences qu'est le backlog. Il y a plusieurs artefacts qui contiennent des exigences : le modèle des cas d'utilisation avec tout ce qu'il contient et les spécifications supplémentaires pour les exigences non fonctionnelles. De plus les demandes de changement vont aussi dans le backlog alors que c'est encore un autre artefact pour le RUP. C'est quand même bien différent dans l'approche. Surtout que le backlog n'est pas une spécification.

En revanche, un artefact du RUP que j'utilise aussi avec Scrum, c'est le document Vision. Très utile.

Il y a moins d'ambiguïté dans les backlogs en anglais peut-être parce qu'on commence par le qualificatif auquel il s'applique

6. Le samedi 10 février 2007, 23:12 par Avangel

Je préfère aussi parler de "liste de tâches", c'est probablement le plus explicite et sans ambigüité. Mais quel que soit le terme, l'important c'est l'idée qu'on y associe derrière soit bien comprise :)