Je vous propose un outil que j'utilise depuis quelques mois dans mon équipe.
L'idée est partie d'un burndown mais sur lequel j'ai apporté une touche de nouveauté.
Constat
Je reprends les bases, un burndown est une représentation graphique de l'évolution de la taille du backlog produit, au cours du temps. Ca s'appelle burndown parce que dans l'idée, le backlog est consommé (il brule), et ca permet de faire une projection de la date d'atterrissage du projet.
Burndown Produit classique (en théorie)
mais en pratique un produit qui vit ca serait plutôt ça
... pas très utile alors.
Quoi ? mais on parle de projet ou de produit?
C'est ça l'ambiguité, cet outil vient avec une dissonance: On réalise un produit, mais le projet a une fin.
Pour info, Il existe 2 autres variantes du burndown classique:
Burndown de Sprint: permet de visualiser si les story sont clôturées au fur et à mesure du sprint ou seulement à la fin. C'est généralement lié à la taille des story. Je n'ai jamais trouvé un grand intérêt à cette représentation, car c'est quelque chose que l'équipe ressent sans avoir besoin de le dessiner.
Burndown de Release: permet de projeter la date de fin de release. A supposer que la date de release est modifiable. Dans mon équipe, nous faisons une release prodable tous les 3 sprints. Mais cela peut être différent dans votre équipe.
Proposition
Et maintenant voici ma proposition: le burndown perpétuel
Dans cette représentation, la taille du backlog reste visible, mais nous avons en plus sa décomposition en Epic. Il reste possible de travailler sur plusieurs Epic en parallèle. L'Epic la plus prioritaire est placée en bas, et nous obtenons une projection de la fin de réalisation de cette Epic.
L'outil parfait ?
Compromis entre 2 visions
Je pense que cette représentation est une bon compromis entre le souhait d'avoir un backlog vivant, une approche itérative (orienté valeur) mais aussi d'avoir une visibilité sur l'atterrissage d'un sujet (orienté date).
En particulier quand on a un gros sujet. Perso mon équipe avait une grande refonte d'IHM à faire et le besoin est parti de là.
Synthétique
Il propose une vue agrégée du backlog, c'est une synthèse du contenu du backlog qui donne un ordre de grandeur de la taille des différents sujets. C'est utile pour une partie prenante qui ne veut pas rentrer dans le détail des story du backlog. Cela permet d'aider à la priorisation à moyen terme.
Objectif
Contrairement à un planning classique, il est objectif. Il raconte l'histoire suivante: "Si l'équipe ne rencontre pas d'impondérable, conserve sa capacité actuelle, et n'est pas interrompue par un sujet plus prioritaire, voici la date à laquelle ce sujet devrait être terminé."
On utilise les mesures du passé pour faire une projection de l'avenir.
Pour être représentatif, l'outil a besoin d'un certain nombre de mesures. la vélocité moyenne est calculée sur 3 sprints, mais pour que la tendance soit fiable, il faut environ 5 sprints.
Cela me ferait plaisir que vous le testiez dans votre contexte et que vous me dites si cela vous a été utile.
Comment le faire vous même ?
Les 3 premiers exemples ont été réalisé avec Google spreadsheet.
Il faut utiliser un graphique en aire avec empilement.
Dans Excel il existe une fonctionnalité de tendance qui permet de visualiser la projection. Par contre cela n'est pas compatible avec l'empilement, il faut donc faire l'empilement "à la main" avec des formules pour faire les sommes, puis ajouter la tendance sur les une ou 2 Epic du bas. Voici ce que ça donne.
Pour aller plus loin
A l'étage le plus haut qui correspond au backlog, il est aussi possible d'y ajouter une projection basée sur la vélocité et non sur la tendance.
Enfin, il est possible de construire le nombre de sprints en vision en divisant la taille du backlog par la vélocité moyenne. Cela permet de dire "l'équipe a du travail pour 2 ans". Etes-vous capable de répondre à cette question pour votre équipe ?
Je peux vous envoyer la version excel sur demande.
Content de vous partager cela.
