backlog

Le backlog initial PermaBio

Le backlog initial PermaBio

Le premier backlog est constitué

Pour notre exemple PermaBio, dans ce premier article consacré à la boucle de feedback (le chapitre 3 de L’art de devenir une équipe agile), nous allons nous intéresser à la constitution du backlog initial.

Il contient des gros morceaux qui seront ensuite affinés.

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.

Partir des structures d'ensemble pour arriver aux détails

Partir des structures d'ensemble pour arriver aux détails

C'est l'arbre qui cache la forêt

Les 6 premiers principes de la permaculture que vous avons présentés considéraient l’élément, tandis que les 6 suivants vont partir du système. Nous passons donc d’une approche bottom-up à du top-down. Principe 7 : Partir des structures d’ensemble pour arriver aux détails Ce principe s’appuie sur le premier principe “Observer et interagir”, dans lequel il s’agissait d’identifier des formes. On pourrait dire pattern à la place de forme, peut-être. Holmgren évoque ici la similarité (des formes) comme un concept important pour le design.
Les chapitres de l'édition 5

Les chapitres de l'édition 5

22 ! C'est le nombre de chapitres.

La structure prend forme. Voici les titres des chapitres pour l’édition cinq de mon livre Scrum. Que des verbes. Parmi les nouveautés, les chapitres 13, 15 et 22. Composer le prélude à Scrum, une métaphore musicale pour la période avant le premier sprint, qui est aussi appelée —à tort— sprint zéro Élaborer le backlog initial, comment faire le premier backlog, en s’appuyant sur des techniques complémentaires comme le story mapping et l’impact mapping.
Le backlog est PROUVÉ

Le backlog est PROUVÉ

Un acronyme pour se souvenir des caractéristiques d'un backlog

En première approche, le backlog est simplement la liste des choses à faire par l’équipe. Cependant, il possède quelques caractéristiques remarquables, qui forment l’acronyme PROUVÉ. Public : le backlog est public pour favoriser la transparence et faciliter le feedback. Réduit : le backlog est de taille réduite pour favoriser la visibilité et faciliter son usage. Ordonné : le Product Owner cherche à maximiser la valeur procurée aux utilisateurs tout en minimisant le travail pour y arriver ; il utilisera ces critères pour définir l’ordre dans le backlog.
La vie de la story a changé en 10 ans

La vie de la story a changé en 10 ans

Une évolution sensible vers du flux

Il y a à peu près 10 ans, j’écrivais un billet “Les états significatifs d’un élément de backlog”. Amusant de le relire aujourd’hui et de constater comment mon approche de Scrum a —légèrement— évolué au fil des ans. Pas beaucoup sur les états, car je décris toujours la vie d’une story avec cinq états, dont les noms ont un peu changé, mais pas les 2 essentiels : prêt et fini.

Scrum 3.0

Une initiative qui n'a pas survécu longtemps

Doug Shimp et Dan Rawsthorne sont les auteurs du livre Exploring Scrum. À mon avis, ce livre est le meilleur qui existe sur Scrum en anglais, le plus fouillé et le plus innovant tout en restant dans l’essence de la méthode. C’est pourquoi je porte une grande attention à l’article Scrum3.0 qu’ils viennent de publier. On y retrouve l’approfondissement de quelques sujets déjà abordés dans leur livre. Parmi leurs propositions :
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.
Critères VRAC pour la priorité dans le backlog

Critères VRAC pour la priorité dans le backlog

Valeur, Risque, Apprentissage, Coût

Prioriser est un néologisme souvent utilisé, et pas que pour un backlog. Avec Scrum, on dit que le PO priorise les éléments du backlog. Bien qu’en fait, il les ordonne. Mais sur quels critères se base t-on ? Dans l'édition 4 de mon livre, chapitre Affiner le backlog, § Revoir l’ordre, page 89, je résume ainsi : L’ordre (ou priorité ordinale) correspond au rang définissant la séquence de réalisation des stories.
Premier Cube à Toulouse dans une semaine

Premier Cube à Toulouse dans une semaine

Le premier Cube à emporter de 1CUBE&GO, que j’anime à Toulouse le 13 décembre, s’intitule “Exprimer et formaliser le besoin”. Ce Cube a déjà eu lieu avec succès à Lyon et d’autres Cubes se déroulent maintenant dans toute la France, avec des animateurs locaux qui se basent tous sur le même concept. => En savoir plus sur le concept de 1CUBE&GO. Pour les Cubes, je reprends la formule de l’invitation gratuite pour un demandeur d’emploi que j’avais mis en place pour mes formations Scrum inter-entreprises.
Exprimer et formaliser le besoin

Exprimer et formaliser le besoin

Tout savoir pour arriver à un beau backlog

Le Cube à emporter de 1CUBE&GO, que j’anime à Toulouse le 13 décembre, s’intitule Exprimer et formaliser le besoin Il est destiné à toutes les personnes qui s’intéressent à découvrir, faire émerger, comprendre, analyser, transmettre et développer le “besoin” pour en faire le bon produit. Il présente une approche pratique qui a maintenant fait ses preuves. Elle est décrite dans les chapitres 14 et 15 de mon livre Scrum, qui pourra être utilisé en complément du Cube :
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.
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.
La vie d'une feature

La vie d'une feature

Un pattern qui va bien

Une feature est un service, observable de l’extérieur, qui contribue à un impact, et dont la description se situe à un niveau tel que toutes les parties prenantes comprennent facilement ce dont il s’agit. Côté développement, une feature peut se voir comme un ensemble de stories et qui a sa propre existence. Un aspect fondamental du développement agile est de répondre à l’impact (et donc fournir de la valeur) en minimisant l’effort à faire pour développer la 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[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.