Bac(klog) de culture

Bac de culutre

J'écris l'édition 3 de mon livre Scrum. Quand mon éditeur m'avait suggéré cette nouvelle édition, j'avais demandé ici dans ce billet ce qu'il paraissait intéressant d'y ajouter.

Dans son commentaire, FXMaq m'a orienté vers le mûrissement de backlog. Bonne idée.

En fait j'en parle déjà dans l'édition deux. Dans le §5.4.2 donc à la fin du chapitre sur le Backlog je conseille dans les choses à essayer de "Cultiver son backlog". C'est ce que FXMaq appelle joliment mûrir et qui vient de l'anglais grooming.

J'en parlais même dans l'édition 1 où j'avais employé le doux verbe bichonner : le Product Owner bichonne son backlog. C'était bien aussi finalement.

Bon, dans la dernière édition, je disais donc cultiver et je vais insister dans l'édition 3 en parlant de culture et même de bac de culture, la partie du backlog où l'on cultive les stories.

J'aime aussi l'idée de mûrissement, mais je l'utilise pour autre chose, métaphore pour les stories finies, que les parties prenantes peuvent récolter, comme on récolte des fruits arrivés à... mûrissement.

Sur le fond, je suis d'accord avec FXMaq : la diffusion de Scrum s'amplifiant, l'usage du backlog s'étend et le besoin pour les PO d'avoir des pistes sur la façon de transformer les idées initiales en stories prêtes à être développées dans un sprint se fait le jour.

Pour collecter ces idées initiales venant de tout le monde, j'avais déjà introduit le bac à sable.

Alors après le bac à sable, voici le bac de culture, l'endroit où on fait pousser de belles stories, jusqu'à ce qu'elles soient prêtes à rentrer dans un sprint.

J'ai déjà le beau dessin de Patrice, mon illustrateur bien aimé, qui va probablement accompagner le texte sur le bac(klog) de culture.

Bac de culutre

Commentaires

1. Le mardi 26 février 2013, 22:01 par Alexis

Impatient de lire cela :)

Et tout à fait en accord avec le commentaire ayant initié cette réflexion... De bonnes pistes pour aider les responsables produits à préparer leurs idées pour en faire de belles histoires à coder est indispensable !

Merci à toi

2. Le samedi 02 mars 2013, 16:05 par FXMaq

Dernièrement, j'ai encore compris pas mal de choses au niveau des critères d'acceptance (CA) par rapport aux tests d'acceptance (TA) en accompagnant une personne devant prendre le rôle de PO sans jamais avoir expérimenté ne serait-ce que l'itératif incrémental.
A quel moment faut il rentrer dans le détail (passer de CAs au TAs) ? ou être dans l'exhaustivité (quelle couverture / dernier moment raisonnable ?). Peaufiner, mûrir, bichonner, là encore il faut expérimenter et se tromper pour être le plus efficient.

Ce que je remarque aussi c'est que bon nombre de POs se retrouvent être le goulet d'étranglement du flux de réalisation du produit et que l'équipe, un Proxy PO, ou une équipe PO doit alors logiquement lui venir en aide, et c'est très bien.
Mais c'est assez ennuyeux quand l'équipe est Prestataire d'un Build et que le PO est le Client car cela a pour effet de diminuer la productivité et peut revenir mettre des tensions contractuelles dans la collaboration (qui peut être bonne entre le PO et l'équipe mais incomprise au niveau des managements respectifs). Il faut alors énormément de transparence et de communication ( certaines personnes ne souhaitent pas voir ce qui est montré ... mais c'est une autre histoire)

Étant en perpétuel apprentissage sur ce sujet, je suis impatient de découvrir le contenu du bac à culture que tu vas nous bichonner! Merci !