Pratique de l'utilisation des Burn Down Charts dans le contexte de SAFe et Scrum

Dans cet article, je prévois de raconter comment, dans ma pratique, nous appliquons le diagramme de combustion (Burn Down Chart) dans le processus de travail selon la méthodologie SAFe

Je vais commencer, sans doute, par le plus intéressant. À savoir par le fait que l'utilisation de ce diagramme dans SAFe ne doit avoir aucune spécificité par rapport à l'utilisation de ce diagramme dans SCRUM. Ou doit-elle ?

Chez nous, SAFe se distingue par la présence d'un rôle tel que RTE, contrairement à SCRUM, où il n'existe pas. Le Burn Down Chart - est un outil de suivi du volume de travail dans le sprint et il est nécessaire avant tout pour l'équipe SCRUM, et non pour quelqu'un d'extérieur, n'est-ce pas ?

Ainsi, je vais tout de même passer à la façon dont nous utilisons le Burn Down Chart, quoi qu'il en soit, et, en restant toujours à l'intérieur du framework SAFe.

Je suis dans le rôle de Scrum Master et je m'efforce de mettre en lumière ce diagramme quotidiennement pour toute la Dev Team. Le moyen que j'utilise - c'est le chat d'équipe, la mention de toute l'équipe via "@", une capture d'écran de l'état actuel du diagramme. La mention de toute l'équipe - c'est un outil assez subtil et il est important de l'utiliser le plus rarement possible (après tout, nous, Scrum Masters, devons aider l'équipe à travailler dans le confort et avec la dispersion minimale possible, n'est-ce pas ?)

Au final, l'équipe voit quotidiennement l'état actuel du sprint et est capable de suivre les événements suivants

• L'apparition d'un travail non planifié
• Le blocage prolongé des tâches dans un statut non terminé
• La prise en compte excessive des risques
• La compréhension - si le travail avance au bon rythme

Ensuite, je vais m'efforcer de dévoiler chacun de ces événements et de donner des exemples tirés de ma pratique.

L'apparition d'un travail non planifié

Sur ce diagramme, on voit très bien comment apparaît un nouveau travail (le deuxième mardi du sprint de deux semaines).

Cas de pratique : "Le développeur, en tant que membre de l'équipe scrum, partageant les principes agile, interagit très bien avec le Product directement. Le Product lui dit qu'il faut implémenter ceci rapidement, tu comprends bien toi-même, ici c'est rapide et les risques sont minimaux.

Le développeur est excellent, il sait tout sur l'agile et sur l'importance de la livraison de la valeur métier, il va ajouter sur le tableau une story du backlog, elle est estimée par l'équipe à 6 sp.

Le reste de l'équipe (à part le développeur et le Product) le remarque lors de la mise à jour matinale du diagramme. Au standup, l'équipe prend une décision sur la façon de gérer cette situation. Très probablement, la story est retirée du sprint, l'équipe fait comprendre au Product et au Développeur qu'on ne peut pas faire comme ça, le product peut placer cette story dans le sprint suivant si nécessaire.

Bien sûr, idéalement, l'équipe devrait remarquer l'apparition d'un nouveau travail au standup et sans le diagramme. Mais le diagramme est un bon indicateur qui réduit les risques de ne pas remarquer un tel changement important pour toute l'équipe au minimum.

Ici, il est important de comprendre que le scénario aurait pu se dérouler différemment selon le niveau de l'équipe. Dans les équipes aguerries, le Propriétaire du produit n'aurait guère fait ainsi, et s'il l'avait fait, il aurait argumenté non pas par le fait que « cela peut être implémenté rapidement », mais par le fait que « j'estime à 55% la probabilité que si cela est implémenté maintenant, cela peut augmenter notre profit de 20% le mois prochain » ou encore par quelque métrique mesurable.

Le blocage prolongé des tâches dans un statut non terminé

Ici, nous constatons que le travail ne se termine pas, même partiellement, pendant très longtemps. Cela peut signaler différents problèmes, j'en énumère quelques-uns

• Mauvaise décomposition des tâches

  Très souvent, les équipes débutantes parlent de l'impossibilité de décomposer. Chez elles, tout brûle le dernier jour, le travail ne se parallélise pas, etc. Bien sûr, il faut travailler là-dessus avec le Scrum Master et expliquer la valeur de la décomposition à l'équipe.

• DOD formulée de manière non optimale

  DOD (Definition of Done) - description des critères de disponibilité d'une User Story dans le sprint. Parfois ils n'existent pas du tout ou sont décrits de manière très abstraite. Cela peut tout à fait être un problème, que, naturellement, le Scrum Master doit aider à résoudre

Prise en compte excessive des risques

Dans ce cas, nous voyons une situation où l'équipe a surévalué les risques.

Il est possible qu'une histoire ait été surestimée. Il est possible que ce soit un problème plus systémique et qu'il faille augmenter le volume de travail lors de la planification du sprint. Dans tous les cas, cette situation n'est pas correcte. Car le business avait planifié que seraient réalisées précisément les tâches du sprint et précisément à la fin du sprint. Selon la façon dont les dépendances ont été planifiées, ici il faudra probablement organiser des réunions pour ajuster les attentes.

Dans ma pratique, cela s'est produit lorsqu'une solution plus rapide que celle discutée lors de l'estimation a été trouvée. Nous avons discuté avec toute l'équipe de quelle histoire nous pourrions clôturer d'ici la fin du sprint et lors de la rétrospective nous avons convenu que nous essaierions de regarder le code lors du grooming. Il s'est avéré qu'il suffisait de simplement jeter un œil au code pour comprendre que la solution était bien plus simple.

Compréhension - le travail avance-t-il au bon rythme

Ici, je voudrais attirer l'attention sur les manières graphiquement peu réussies d'afficher le Burn Down Chart

Dans la partie supérieure de l'image est donné un exemple de réalisation graphique pas des plus réussies pour deux raisons que j'exposerai ci-dessous.

• L'ajout de nouveaux SP dans le sprint n'est pas visible

  Ici, sur le diagramme supérieur, il n'est pratiquement pas visible que du travail non planifié a été ajouté. Sur celui du bas, c'est plus parlant.

• Le reste de travail relatif n'est pas affiché correctement

  Selon le diagramme supérieur, il reste encore 3 jours de travail. En réalité, il en reste 2, le jour de repos, peut-être que quelqu'un prévoit de se reposer.

Bien sûr, certains trouveront ces détails insignifiants. Mais il faut comprendre que chaque membre de l'équipe ne jettera qu'un coup d'œil à ce diagramme et qu'il doit transmettre un maximum d'informations utiles.