affinage

L'affinage du backlog PermaBio

L'affinage du backlog PermaBio

À la soupe !

Nous avions laissé notre exemple PermaBio, après le premier article consacré à la boucle de feedback, sur la constitution du backlog initial.

Les gros morceaux qui y figurent vont maintenant être décomposés en plus petits.

Le backlog PermaBio suite à l'affinage

Le backlog PermaBio suite à l'affinage

Le backlog présenté en trois parties pour mieux y voir ce qu'il y a à faire

Notre premier backlog PermaBio contient des morceaux de fonctionnalité. Le gros morceau le plus prioritaire, la soupe, a été décomposé en plus petits morceaux.

Ces morceaux sont appelés des stories dans les équipes. Des exemples de stories pour PermaBio sont présentés page 62 de L’art de devenir une équipe agile.

Affiner le backlog

Affiner le backlog

Chapitre 7 : deuxième partie sur le backlog avec la vue dynamique, l'affinage.

Une story trop grosse doit encore être affinée pour entrer dans un sprint.

Ne pas produire de déchets

Ne pas produire de déchets

Un point à temps en vaut cent

Le principe 6 de la permaculture c’est : Ne pas produire de déchets Ce principe est illustré par le ver de terre, ce qui fait comprendre le titre comme ne pas produire de déchets à l’extérieur de l’écosystème. Les vers de terre de l’écosystème se chargent de recycler les déchets. Le premier proverbe est : Pas de gaspillage, pas de manque. Holmgren utilise une définition de Bill Mollison, l’autre fondateur de la permaculture : un polluant (déchet) est un produit de n’importe quelle partie d’un système qui n’est pas utilisé de manière productive par une autre partie du système.
Les activités de l'affinage du backlog

Les activités de l'affinage du backlog

ADAPTER

L’affinage du backlog (en anglais Backlog Refinement) se pratique avant le premier sprint, puis pendant chaque sprint. L’objectif de l’affinage est d’augmenter les chances de succès des futurs sprints, en entretenant le backlog. Voici les activités qu’on y mène, en équipe. Le moyen mnémotechnique pour retrouver ces activités : ADAPTER L’affinage se déroule entre le Product Owner et le reste de l’équipe, à un moment laissé à l’appréciation du collectif, soit sur un rythme régulier (ce qui est plus facile), soit à la demande.
Les 6 activités de l'affinage du backlog

Les 6 activités de l'affinage du backlog

Un nouveau chapitre consacré à l'affinage dans l'édition 4 de Scrum

Il y a tout juste un an, je consacrais beaucoup de mon temps à l’écriture de Scrum#4. Des efforts récompensés, cette nouvelle édition a finalement été publiée en octobre et, depuis, elle s’écoule bien : nous avons dépassé les 2000 exemplaires en mai et elle est toujours bien classée chez Amazon. L’édition 4 comporte de nombreuses nouveautés. En particulier, apparait un chapitre dédié à l’affinage du backlog. Le schéma présente les activités d’affinage.
Décider qu'une story est prête

Décider qu'une story est prête

Les 6D pour aider à la décision

Début juin 2015, en pleine écriture de mon livre, je n’avais encore que 4D et demi. Dans l’édition 4, il y a bien les 6, pages 82 et 83, chapitre Affiner le backlog. Voici l’extrait qui en cause : C’est l’équipe qui décide si une story est prête. Pour prendre sa décision, elle pourra s’appuyer sur une liste de vérifications, la définition de prêt. La définition de prêt est élaborée par l’équipe et dépend du contexte.
Glossaire A-B

Glossaire A-B

Abécédaire de l'agilité

Dans la nouvelle édition de mon livre, j’ai ajouté un glossaire qui n’existait pas dans les éditions précédentes. Je l’ai voulu assez court (il y a 70 entrées) et avec des définitions brèves. Voilà ce que ça donne pour les entrées A et B : Affinage du backlog : activité qui consiste à entretenir le backlog pour augmenter les chances de succès des futurs sprints. Agilité : capacité d’une organisation à fournir tôt et fréquemment des services impactant ses utilisateurs, tout en s’adaptant à temps aux changements dans son environnement.
Session d’affinage et affectation des features (SAAF)

Session d’affinage et affectation des features (SAAF)

Quand décider quelle équipe s'occupe de quelle feature ?

Le passage à grande échelle avec des features teams demande une prise de décision supplémentaire : le choix de l’équipe qui va réaliser une feature. Comme pour les travaux d’affinage sur les stories, il est souhaitable que cela se fasse autour de conversations, mais impliquant cette fois toutes les équipes. C’est l’objet des sessions d’affinage et d’affectation des features. Pour un Scrum à plusieurs équipes, le tableau des features permet de montrer quelle équipe va travailler sur quelle feature.
Finir une story c’est bien, finir une feature c’est mieux

Finir une story c’est bien, finir une feature c’est mieux

Arrêter de commencer, commencer à finir. Mais pas seulement.

Il y a quelque temps, j’avais audité un projet dont le tableau de features, s’il avait été fait[1], aurait ressemblé à peu près à ça : Tout un tas de features commencées, aucune de finie, même après des mois de sprints. Avec cette vue, on voit bien que l’avancement peut être résumé très vite. Zéro. Rien de fini. Pas besoin de feuille de calcul. Pourtant sur le projet, l’avancement n’était pas présenté comme ça : il y avait des stories de finies, une vélocité obtenue à chaque sprint.
Epics et Stories

Epics et Stories

Une epic est une story qui est trop grosse pour entrer dans un sprint

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.
La purge du backlog

La purge du backlog

Il ne faut pas hésiter à jeter

Suite de la série sur l'affinage du backlog. 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.
Les participants à l’affinage de backlog

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

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).
Les travaux d'affinage du backlog

Les travaux d'affinage du backlog

Des travaux basés sur des conversations avec le Product Owner

Les travaux d'affinage consistent en : avoir une compréhension partagée de quelques stories pour qu’elles soient prêtes pour le sprint revoir l’ordre des stories (les priorités) décomposer des stories non élémentaires (epics) estimer ce qui n’est pas encore estimé (si on estime) approvisionner avec de nouvelles stories purger le backlog Ces travaux sont principalement effectués collectivement, 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.

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).

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”.