Le backlog, la liste des stories

Chapitre 5

Après le chapitre 2, je continue la préparation de la deuxième version de mon livre par le 5, qui porte sur le backlog de produit.

Je n'ai pas eu de retours sur ce chapitre, à part celui de mon beau-frère qui a vitupéré contre l'emploi de l'anglais dans un livre en français. Bon, pour ça, j'avais essayé de franciser quelques termes il y a déjà longtemps et je ne vais pas recommencer maintenant.

Dans la version actuelle, ce chapitre comporte 4 grandes parties :

  1. LE BACKLOG, LA LISTE UNIQUE DES STORIES
  2. LA NOTION DE PRIORITÉ DANS LE BACKLOG
  3. UN ÉLÉMENT DU BACKLOG
  4. GUIDES D'UTILISATION DU BACKLOG

Je viens de relire la première partie, "le backlog, la liste unique des stories", qui est structurée de la façon suivante :

  • Utilisateurs du backlog
  • Vie du backlog
    • Émergence progressive
    • Changements continuels
    • Utilisation continue
  • Options de représentation du backlog

En la relisant, j'ai trouvé que la trame de cette partie était améliorable. L'objectif est d'expliquer ce qu'est le backlog et cela pourrait être présenté de manière plus efficace.

Après avoir réfléchi à la façon de refactorer (oups, mon beauf va encore râler !) cette partie, voilà la nouvelle organisation que j'envisage, sous forme de questions :

  • Qu'est ce que le backlog ? C'est une liste, unique, des stories...
  • A quoi sert le backlog ? Présentation des activités impactées par le backlog : ingénierie des exigences, gestion de projet, conception, test....
  • Qui l'utilise ? C'est la partie utilisateurs, élaguée du texte sur les activités
  • Quand l'utilise t-on ? C'est la partie Vie du backlog restructurée
  • Comment le concrétiser ?

Je me dis que ce serait bien d'ajouter un nouveau paragraphe : Ce que n'est pas le backlog, dans lequel je pourrais rapporter quelques idées fausses sur le backlog :

  • le backlog n'est pas un référentiel (eh non)
  • le backlog n'est pas une spécification
  • le backlog n'est pas une todo liste

Si vous avez d'autres idées et propositions pour améliorer cette partie, c'est le moment.

Billets en rapport :

Commentaires

1. Le lundi 16 août 2010, 23:00 par francois michas

Bonsoir Claude,
Dans la série, je ne suis pas agile mais je me soigne, les questions d'un gars encore encombré par des templates méthodo et régulièrement noyé sous la cascade :
- sans être une todo liste le backlog peut-il contenir des histoires de type "gestion de projet" ? Il y a bien des histoires de type technique ...
La gestion de projet "récurrente" est essentiellement faite de façon collective pendant les réunions du cérémonial. L'élimination d'obstacles, qui pourrait être considérée comme de la gestion de projet, vient généralement dans une liste à part. Quoi d'autre ? - pour inciter une équipe à se poser des questions sur l'interaction de son produit avec le reste d'un SI ne peut-on pas imaginer des stories type ?
Pourquoi pas mais l'incitation paraît bien légère. - si le backlog n'est pas un référentiel, ne contribue-t'il pas aux éléments documentaires minimaux qui survivront au projet et auront une chance d'être maintenus durant la vie de l'application fabriquée ?
ces éléments, ce sont les tests (qui remplacent la spec) - comment fait-on le lien entre les stories du backlog ?
quel lien ? une dépendance ? Assez de bêtises pour ce soir.

2. Le mercredi 18 août 2010, 21:23 par Cyrille

Salut Claude,

Voici mon retour.
Je pense qu'un exemple peut-être intéressant; il permet de comprendre la notion de nouvelles stories, découper une story et de priorisation....

oui, je vais essayer de mettre plus d'exemples dans les différents chapitres, en plus du gros exemple qui est dans le chapitre 18.

Je n'utilise pas les Stories default pour gérer les bugs : ça pourrait être bien de détailler comment tu vois la gestion des bugs dans le backlog.

C'est présenté page 218 en fait, dans la partie Ingénierie du logiciel.

J'ai apprécié la remarque page 59 : "pas de changement durant le sprint mais je pense qu'elle devrait être écrite en police 50, gras et soulignée ;-)

C'est très souvent souhaitable, mais ce n'est pas toujours possible, voir mon article Scrum et les changements pendant un sprint.

Personnellement, j'aime bien refaire une estimation des stories "de temps en temps" car on affine les estimations par rapport à ce que l'on a déjà réalisé, ce point est peut-être détaillé dans un autre chapitre.

On peut le faire lors des réunions de planification de release (chapitre 6), mais c'est rarement nécessaire.

Après il y a les exceptions, l'équipe peut embarquer une story d'une priorité plus faible car elle est moins "grosse" et rentre dans la capacité du sprint mais ce qui "prône" est l'accord du PO suite aux propositions de l'équipe.

++

Cyrille

3. Le lundi 23 août 2010, 15:43 par Ronan

Bonjour,

Après 13 années dans l'industrie automobile dont 10 en logistique, me voici dans la gestion de projet informatique en tant qu'AMOA.
Je me permet de vous donner ma vision de ce qu'est un backlog pour un logisticien lorsqu'il livre un client automobile : c'est le retard de livraison, ce qui reste à livrer. Avec mon vécu, c'est comme cela que je le comprends et je trouve que cela colle avec le backlog du produit.
Votre avis ?

Oui c'est ce qui reste à livrer, mais ce n'est pas du retard : un backlog peut ne jamais être vide et les livraisons régulières.