Affinage

L’affinage est l’activité qui consiste à conserver le backlog prêt à alimenter l’équipe.

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.

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.

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

Le problème, c'est la solution !

Continuons avec le 6e principe de la permaculture appliquée à l’agilité. Un principe avec un fameux proverbe !

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. Une façon simple pour démarrer est de se baser sur 6 caractéristiques de la story, les « 6D ».

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], aurait ressemblé à peu près au schéma (il y avait à la place un gros tableau excel avec des calculs précis —mais faux— d’avancement donnant des % de finition par feature.)

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.

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.