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.
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.
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.
Un nouveau chapitre consacré à l'affinage dans mon livre Scrum
Il y a tout juste un an, je consacrais beaucoup de mon temps à l’écriture de Scrum édition 4. Des efforts récompensés, cette nouvelle édition a finalement été publiée en octobre et, depuis, elle s’écoule bien :
Début juin 2015, en pleine écriture de mon livre Scrum, 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 ».
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.
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.)
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 ni passer dans le bac de départ pour le sprint.
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.
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.
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.
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.
Les notions manipulées pour aller de la vision à la story, avec quelques techniques de définition de produit pour y arriver.
Ce quadrant montre 5 outils et 6 concepts situés dans 4 cases.
Encore une revue ? Oui mais pour gagner du temps !
Bien souvent, la revue de planification de sprint dure longtemps, trop longtemps, suite à des discussions parce que l’équipe a du mal à voir le périmètre des histoires d’utilisateur proposées par le Product Owner. Pour éviter de dépasser la durée normale de cette réunion, il arrive que l’équipe accepte d’inclure une histoire dans le sprint courant alors qu’elle ne sait pas bien la décomposer en tâches. Cela risque de provoquer des problèmes dans le déroulement du sprint.
Pour éviter cette dérive, je propose d’ajouter une revue, un peu avant la fin du sprint précédent.
