Série - Affinage du backlog

Fil des billets - Fil des commentaires

Affiner c’est mieux que groumer

Vendredi toute la journée, mes interlocuteurs ont parlé de grooming.

C’est ainsi qu’ils nomment la discussion sur le backlog, en vue de le préparer, que j’appelle -j'appelais- la revue de backlog.

Ce n’est pas un mot qu’ils ont inventé. C’est moi qui les ai formés. Dans le petit guide Scrum de Schwaber & Sutherland, dans la version 2011, et probablement avant, c’était le terme employé. J’ai dû leur dire et c’est devenu une habitude.

Moi, je l’ai d’abord traduit par bichonner. C’est vrai ! la preuve : le PO bichonne son backlog.

Ensuite je suis passé au PO qui cultive son backlog et j’ai parlé de culture de backlog et de bac de culture. Ce sont ces termes que j’utilise dans l’édition 3 de mon livre, chapitre 5.

Bac de culutre

Force est de constater que ce n’est pas terrible. Le mot culture est maintenant utilisé en agilité, on parle beaucoup de culture d’organisation. Cultiver son backlog peut certes contribuer à changer la culture d’organisation, mais il ne s’agit pas de la même culture.

Entre temps, dans le petit guide Scrum de 2013, grooming est devenu refinement.

Mais mes scrumeurs continuent à dire grooming, c'est rentré dans leur jargon (qui est fleuri). Ils vont même beaucoup plus loin, puisqu’ils ont créé le verbe groomer. Et par extension ils l’appliquent aux stories et autres éléments d’un backlog. Ça donne des horreurs du genre : On a encore ces stories à groomer. Ou bien lors de la rétrospective : Il faut qu’on groome un peu mieux. C'est amusant le franglais et ça ne m'agace plus trop. Mais groumer c'est du (vieux) français qui signifie grogner…

Je sens bien que ma culture (de backlog) ne va pas passer. Alors je change officiellement : puisque refinement est le terme officiel en anglais, je vais utiliser sa traduction.
Attention, pas raffinement ! Pour avoir des backlogs raffinés, il faudrait des très jolis post-it.

Non, la bonne traduction est affinage, du verbe affiner. Donc maintenant je ne cultive plus mon backlog, je l’affine. Je ne vais plus en revue de backlog, je vais en meeting d’affinage de backlog (MAB).

Affinage, va falloir que je demande un nouveau dessin à Patrice, avec des fromages…

Affinage de bac en bac

Des petits bacs plutôt qu'un gros backlog, l'idée a maintenant fait son chemin. C'est plus facile pour l'affinage.

L'idée des bacs m'est venue quand j'étais encore Product Owner d'iceScrum, il y a 3 ans. Il y avait déjà le bac à sable, puis s'est ajouté le bac à glace. Pour iceScrum, ça s'est arrêté là, mais j'ai continué à expérimenter cette façon de présenter le backlog. C'est devenu "les bacs".

L'expérimentation a été un succès. J'ai présenté "les bacs" dans la 3ème édition de mon livre Scrum. J'en ai parlé dans les conférences, par exemple à Toulouse. J'ai vu des équipes l'utiliser. D'autres ont essayé, ont trouvé ça bien. Un retour d'expérience les bacs de culture c'est kiss a été publié par un expérimentateur rock'n roll (si on considère que Kiss c'est du rock) début 2014.

L'intérêt croissant pour le management visuel et la diffusion de Kanban autour de Scrum ont contribué à pousser à mieux comprendre la vie de la story avant le sprint. Dans son livre Kanban pour l’IT, Laurent Morisseau présente dans le chapitre 28, Kanban pour le Product Owner, des colonnes de maturation du backlog qui ressemblent à mes bacs.

Pourquoi les bacs ?

C'est pour faciliter le travail d'affinage du backlog, par l'équipe. On sait qu'il est important pour que le sprint se passe bien. Il vaut mieux que les stories soient prêtes pour les embarquer dans le sprint.

Hop, on crée un bac pour mettre les stories prêtes, c'est le bac de départ. Avec ce bac bien visible, plus facile de savoir s'il y assez de stories prêtes ou s'il n'y en n'a pas trop.

Dans le reste, il y a des idées, des demandes, des feedbacks, peut-être intéressants, mais que le Product Owner n'a pas encore examinés. Hop, dans le bac à sable, inutile de perturber l'équipe avec ça.

Il en reste déjà moins. Mais et en particulier si on livre à chaque fin de release, il y a sûrement des stories qu'on va développer, oui mais pas tout de suite, ce sera dans la prochaine release. Hop dans le bac à glace, ce serait dommage que les développeurs passent du temps dessus.

Ce qui reste alors, ce sont les stories (ou epics) sur lesquelles faire le travail d'affinage. Hop on les met dans le bac d'affinage (c'est le nouveau nom du bac de culture).

Nous avons donc un bac, plus petit qu'un backlog classique, où on va travailler (affiner) et les trois autres qui correspondent en gros à des files d'attente. Avec les bacs, c'est déjà plus clair.

Nous verrons dans un prochain numéro quand se déroulent ces travaux d'affinage.

Quand faire l’affinage du backlog ?

When to refine the backlog?

L’affinage du backlog (refinement backlog, previously backlog grooming) est une activité faite par l’équipe pendant un sprint, dans le but de préparer des stories pour les prochains sprints.

Dans quel cadre est-il pratiqué ?

Une grande partie de ce travail est constitué de discussions entre le Product Owner et le reste de l’équipe. On peut donner un caractère permanent, officiel, à ces rencontres en les plaçant dans la cadre d'une réunion d'équipe, le meeting d’affinage de backlog (le MAB).

Quand a lieu ce meeting ?

Là encore deux possibilités :

  • à un rythme régulier. Par exemple, toutes les semaines le mercredi.
  • sur demande. C’est plus agile : le ScrumMaster surveille le bac de départ et s’il constate qu’il y a un risque de famine en stories prêtes, il déclenche un meeting d’affinage de backlog.

Si on pratique du Scrum kanbanisé avec limites, on peut ajouter une limite basse sur ce bac de départ et c’est son franchissement qui déclenche le meeting.

Combien de temps y consacrer ?

Si l’équipe consacre 2 heures par semaine à ce meeting, cela fait environ 5% de son temps et c’est raisonnable. Le guide Scrum 2013, qui ne donne pas de minimum, parle d'un maximum de 10% pour l’affinage du backlog.

Si ces meetings ne suffisent pas, l’affinage pourra être complété par le PO, dont c’est le boulot. Si le PO a besoin d’aide de membres de l’équipe, par exemple pour décomposer une epic en stories, le mieux est de créer une story de découverte.

Nous verrons dans un prochain numéro le détail des activités faites dans un MAB.

Les travaux d'affinage du backlog

Affinage avec les bacs

Les travaux d'affinage consistent en :

  1. avoir une compréhension partagée de quelques stories pour qu'elles soient prêtes pour le sprint
  2. revoir l'ordre des stories (les priorités)
  3. décomposer des stories non élémentaires (epics)
  4. estimer ce qui n'est pas encore estimé (si on estime)
  5. approvisionner avec de nouvelles stories
  6. purger le backlog

Ces travaux sont principalement effectués lors d'un MAB, au moment où l'équipe le décide.

Le détail et l'ordre des activités menées lors d'une séance d'affinage dépendent de la situation. Les 3 bacs : bac à sable, bac d’affinage, bac de départ, aident beaucoup à organiser les activités :

  • s'il n'y a pas assez d'éléments dans le bac de départ, y ajouter des stories prêtes est primordial (activité 1)
  • on réordonne le bac d'affinage (activité 2) pour mieux voir ce qu'il faudrait décomposer (activité 3)
  • on examine les éléments du bac à sable pour approvisionner le bac d'affinage (activité 5)
  • dans le bac d'affinage, les éléments issus de l’approvisionnement (activité 5) et de la décomposition (activité 3) peuvent être estimés (activité 4)
  • on purge les éléments du bac à sable non retenus et, éventuellement, certains du bac d'affinage rejetés après discussion (activité 6)

Les participants à l’affinage de backlog

L'affinage consiste, à partir de l'idée brute, à rendre une story prête à être réalisée en un sprint.

La vie de la story

Dans la série sur l'affinage du backlog, après avoir vu le pourquoi, le quand et le quoi, voyons le qui.

Bien évidemment en premier lieu vient le Product Owner. C’est lui le principal affineur.

Il affine pendant le MAB, mais aussi en dehors, car il peut faire seul des travaux d’affinage comme :

  • approvisionner à partir du bac à sable,
  • revoir l’ordre du bac d'affinage,
  • purger les bacs.

Pour les autres travaux, il s’appuiera volontiers sur des membres de l’équipe ou des parties-prenantes spécialistes du domaine (des experts du sujet).

La décomposition d’un gros morceau (epic) en stories élémentaires sera probablement l’activité pour laquelle des experts fonctionnels en dehors de l’équipe peuvent le plus l’aider.

Pour apporter des précisions à une story afin qu’elle devienne prête, ces experts peuvent aussi aider, mais ceux qui décident si la story est prête sont les développeurs de l’équipe, c’est donc mieux de les impliquer dans cette activité d’affinage.

L’estimation en points, si elle est faite, est un travail collectif de toute l’équipe Scrum.

On voit donc que certaines activités nécessitent la présence de toute l’équipe et d’autres ne l’imposent pas. C'est à chaque équipe d'organiser l'affinage du backlog :

  • Une équipe partageuse déroulera toutes les activitiés lors des MAB, auquel tout le monde participera.
  • Une autre équipe pourra se contenter de réduire un MAB à des conversations pour estimer (planning poker) et évaluer l’état prêt de quelques stories.

La purge du backlog

Rejet à partir des bacs

Suite de la série sur l'affinage du backlog : il ne faut pas hésiter à jeter.

Pour éviter d’avoir un trop gros backlog, une première solution est de le diviser en bacs.

En complément il convient de purger régulièrement ces bacs. Les éléments qui y stagnent trop longtemps sont des bons candidats à la purge.

Purger le bac à sable

Éliminer des éléments du bac à sable est une activité récurrente du Product Owner.
Parmi les demandes qui sont faites dans ce bac, c’est à lui de décider ce qu’il veut dans son produit ou son service. Plutôt que de laisser traîner une demande qu’il ne veut pas satisfaire dans le bac à sable, il la supprime.

Sur ce sujet on pourra relire 2 anciens billets :

Purger le bac d’affinage

Enlever des éléments qui sont entrés dans le bac d’affinage est aussi possible. Le PO les a fait entrer comme des options, il n’y a pas d’engagement à ce niveau-là.

De plus, dans le bac d’affinage on trouve des stories résultats de la décomposition de plus grosses stories (ou epics). Il est tout à fait possible que certaines soient jugées inutiles pour la release courante.

Purger le bac de départ

Éliminer des stories déjà prêtes qui sont dans le bac de départ doit rester exceptionnel, mais ça peut arriver et il est préférable de rejeter à ce moment que de passer du temps à réaliser quelque chose qui n’apporte pas de valeur.

Taux de rejet

Il me paraît intéressant de collecter le nombre de stories rejetées dans chaque bac (et peut-être aussi la durée de vie avant rejet), pour obtenir un indicateur « taux de rejet » et suivre son évolution.

Epics et Stories

Epic et story dans le bac d'affinage

Une équipe qualifie une story d'epic pour indiquer qu'elle devra être décomposée en plusieurs stories[1].

Pour le dire autrement, il s'agit d'une story qui est trop grosse pour entrer dans un sprint.

On sait qu’il faudra la décomposer, sans quoi elle ne pourra pas devenir prête et passer dans le bac de départ pour le sprint.

Quand identifie t-on l'epic ?

Je suggère qu’au moment où un élément entre dans le bac d’affinage, on décide rapidement de le qualifier comme epic ou comme story.

Cette distinction est, de préférence, rendue visible (couleur, forme de post-it, gommette, indication ou toute autre idée qui convient à l’équipe).

Quand décompose t-on l'epic ?

La décomposition est faite pendant l'affinage. C'est une des choses qu'on peut faire en équipe lors d'un MAB.

Usage de l'epic

  • Interdit de rentrer un epic dans le bac de départ.
  • On peut changer d’avis : une story peut devenir epic et vice-versa, pourquoi pas.
  • Dans le bac d’affinage on pourrait se dire qu’on a 2 sous-bacs, un pour les epics et l’autre pour les stories. Mais comme il arrive qu’une epic puisse être plus prioritaire qu’une story, il vaut mieux ne conserver qu’une seule liste ordonnée et reconnaitre les epics par un signe visuel.
  • Si on fait un plan de release on est amené à estimer les epics (en points, ou en considérant que l'epic vaut x stories si on compte).
  • Une fois la décomposition faite, l'epic disparaît, il ne reste que les stories.

Note

[1] C'est ce que je disais déjà en 2007 (je n’utilise plus la notion de thème).

Bac d'affinage et plan de release

Diagramme de bacs empilés

Dans une situation où il est nécessaire d’avoir un plan à moyen terme -un plan de release- voilà comment se servir du bac d’affinage.

Plan de release, ou pas, c'est la question. Si la réponse est oui, les bacs facilitent grandement son élaboration et son suivi.

Pendant le sprint zéro (ou après), on place dans ce bac tout ce qu’on prévoit de faire pour la date de fin de release. Bien sûr il ne s’agit pas de tout décomposer en stories, donc on se retrouvera aussi avec des epics.

L’objectif devient de vider ce bac d’affinage pour la fin de la release.

On peut estimer en points son contenu, qui représente ce qu'il y a à faire pour la release. On peut tout simplement compter les stories et epics, si on a des données statistiques indiquant, par exemple, qu’en moyenne un epic vaut 3 stories.

Pendant le déroulement des sprints, le bac d'affinage va évoluer :

  • des stories prêtes vont passer dans le bac de départ,
  • de nouvelles stories vont apparaître, soit par décomposition des epics soit par approvisionnement à partir du bac à sable,
  • le Product Owner pourra aussi purger des stories et, surtout en fin de release, déscoper en plaçant les stories repoussées à la prochaine release.

C'est là qu'intervient le bac à glace dans lequel on met tout ce qui n'est pas pour la release courante. Une fois la fin de la release atteinte, le bac d’affinage sera réapprovisionné par injection à partir du bac à glace.

Comme indicateur on utilisera un burndown de release ou mieux un burnup à deux courbes, ou encore mieux un diagramme de bacs empilés, comme ci-dessus.