3 rapports de burndown agiles et comment les utiliser

Les pratiques agiles, pour les non-initiés et sous-informés, peuvent parfois apparaître comme des méthodologies ad hoc de développement logiciel et de gestion de projet. La vérité est bien différente.

L'un des 12 principes des logiciels agiles stipule que «les meilleures architectures, exigences et conception émergent d'équipes auto-organisées», mais la plupart des organisations qui appliquent des pratiques agiles, y compris Scrum et Kanban, appliquent des rituels et des rituels de processus importants. Par exemple, de nombreuses organisations mettent en œuvre des pratiques de planification agiles, notamment l'estimation des points d'histoire, les normes d'architecture et les disciplines de gestion des versions pour améliorer l'impact commercial, la qualité et la fiabilité des versions d'applications.

La plupart des équipes choisissent d'utiliser un outil agile tel que Jira Software ou Azure DevOps pour gérer les backlogs, les sprints et la collaboration entre les équipes agiles. L'objectif principal de ces outils est de gérer de manière centralisée les exigences, l'état du sprint, le flux de travail et la collaboration entre les membres de l'équipe agile et plusieurs équipes agiles. Cependant, plus les organisations font preuve de rigueur dans l'utilisation de ces outils, plus ces outils peuvent aider les dirigeants et les équipes à identifier les problèmes, à rendre compte aux parties prenantes de l'état d'avancement et à améliorer leur exécution.

L'un des rapports prêts à l'emploi les plus courants est le rapport de burndown. Étant donné que les pratiques agiles permettent aux propriétaires de produits de redéfinir les priorités du backlog en fonction des commentaires des clients, les rapports traditionnels tels que les diagrammes de Gantt ne parviennent pas à capturer la nature fluide de l'exécution agile. Un élément fondamental du diagramme de burndown est qu'il tient compte du travail terminé, du nouveau travail ajouté à la portée et d'autres modifications de la portée. Le diagramme de burndown peut fournir une image rapide de la façon dont les équipes progressent vers leurs objectifs.

Lire un graphique de burndown de sprint

Les graphiques Burndown ont généralement un temps sur l'axe des x et des estimations sur l'axe des y. De nombreuses équipes estiment en points d'histoire, mais de nombreux outils agiles peuvent tracer les burndowns en fonction du nombre d'articles ou d'estimations en heures. Pour cet article, je suppose que les story points sont utilisés.

Le rapport de burndown de sprint trace le nombre de points d'histoire qui sont dans la portée de l'intervalle de temps. Au fur et à mesure que l'équipe termine les histoires, le graphique montre comment elle «brûle» la liste des histoires et d'autres types de travail (problèmes dans Jira, types d'éléments de travail dans Azure DevOps) jusqu'à ce que le travail soit terminé ou que le sprint se termine. Lorsque les équipes terminent le travail engagé dans le sprint, la ligne tracée coupe l'axe des x, indiquant que tout est terminé.

Le burndown de sprint est le plus simple à conceptualiser. Le premier jour du sprint, l'équipe s'engage sur certaines histoires et le nombre total de points d'histoire. Si vous examinez le graphique de burndown ce jour-là, vous devriez voir un seul point sur l'axe des y représentant le nombre de points sur lesquels l'équipe s'est engagée le jour zéro du sprint.

Au fur et à mesure que les histoires sont marquées comme terminées, le burndown du sprint montre le nombre de points restant à terminer.

Comment un burndown de sprint est-il utilisé en pratique? Un burndown sain montre une courbe linéaire et idéalement exponentielle jusqu'à zéro. Si la courbe a une pente plate au début d'un sprint, cela peut indiquer des blocs ou beaucoup de travail en cours et que le sprint peut être à risque. Un burndown plat ou en pente lente peut être très problématique si de nombreux tests sont effectués sur des histoires complètes de code et si le travail de test ne peut pas commencer avant les derniers jours du sprint.  

Un burndown de sprint rapidement descendant est généralement une bonne chose, mais cela peut indiquer que l'équipe est sous-engagée ou a seulement choisi de prendre des histoires plus petites dans le sprint.

Les burndowns épiques suivent les progrès par rapport aux pilotes commerciaux et techniques

Les burndowns de sprint sont très utiles pour suivre l'exécution à court terme et aident les équipes à respecter avec succès les engagements de sprint. Pour mieux suivre les progrès par rapport aux objectifs à plus long terme, les burndowns épiques et de version fournissent la visibilité nécessaire.

Les burndowns épiques fonctionnent mieux lorsque les équipes définissent plusieurs efforts de longue durée, tels que la mise en œuvre de capacités majeures pour l'utilisateur final, des stratégies de dette technique, des améliorations de performances ou des évolutions de processus. Pour profiter des burndowns épiques, le backlog doit avoir:

  • Entre cinq et 15 épopées qui dureront au moins plusieurs mois et nécessiteront au moins six sprints.
  • Des fonctionnalités, des histoires et des stubs d'histoire qui se retrouvent sous l'épopée et représentent un plan de haut niveau à exécuter sur l'épopée.
  • Estimations de haut niveau, idéalement en points d'histoire pour chaque histoire ou talon d'histoire qui se déroule sous les épopées.

Une fois ceux-ci en place, le burndown épique décrit les changements apportés à ce plan. Son axe x représente les sprints et l'axe y représente l'estimation totale des histoires et des stubs d'histoire attribués à l'épopée. Dans le graphique burndown épique de Jira Software, vous voyez un graphique à barres avec une couleur représentant les histoires terminées dans le sprint et une seconde qui montre les points d'histoire ajoutés. Les points d'histoire augmentent lorsque de nouvelles histoires ou des talons d'histoire sont ajoutés à l'épopée ou lorsque les estimations changent.

Il existe plusieurs façons d'utiliser le graphique de burndown épique:

  • Il illustre la vitesse de réalisation des fonctionnalités et des histoires par rapport au plan. Lorsque les plans sont précis et la vitesse de l'équipe cohérente, cela peut fournir un indicateur lorsque le travail de l'épopée est terminé.
  • La plupart des plans agiles ne sont pas terminés et les équipes ajoutent, modifient et suppriment des histoires en fonction des commentaires des utilisateurs finaux, de la découverte de complexités techniques et de la résolution de la dette technique introduite au cours du voyage. Le burndown épique indique alors à quel point l'épopée est loin du plan en fonction de la croissance du backlog par rapport à son achèvement sprint par sprint.
  • Les burndowns épiques aident également à comparer les efforts sur plusieurs sprints et à évaluer la quantité de travail de planification et de livraison effectuée dans une épopée par rapport aux autres.

Les burndowns de publication indiquent aux équipes si les versions atteindront la date et la portée

Les équipes avancées qui automatisent entièrement leurs pipelines de livraison avec une intégration continue, des tests continus et une livraison continue peuvent ne pas avoir besoin de burndown de versions. Les équipes qui déploient fréquemment doivent suivre les fonctionnalités et les histoires liées à la version, mais le burndown de la version n'est pas très utile car il suit souvent la progression par sprint.

Pour les autres équipes qui suivent les pratiques de gestion des versions et qui normalisent les versions multi-impressions, le burndown des versions peut être l'outil le plus important du propriétaire du produit et de l'équipe.

Le burndown de publication est similaire au burndown épique, sauf qu'au lieu de suivre les fonctionnalités, les histoires et les stubs d'histoire affectés à une épopée, le burndown de publication montre ce qui est attribué à une version. L'axe et les barres sont alors identiques à des burndowns épiques.

Les équipes utilisant des burndowns de version peuvent ainsi suivre la portée et le calendrier d'une version. Les équipes qui sont sur la bonne voie verront une pente de burndown vers l'axe des x avec une pente cohérente avec la vitesse de l'équipe. Les versions qui peuvent dévier de la piste ont une pente plus petite ou décrivent plus de points d'histoire ajoutés (lorsque plus de portée est ajoutée à la version) que ce qui est en cours de réalisation.

Jira Software vous aide avec ces projections. En supposant que l'équipe travaille sur le projet depuis au moins trois sprints, Jira Software calculera une vitesse d'équipe moyenne et prédira le sprint final pour une version basée sur cette vitesse.

Les burndowns de sprint, d'épopées et de versions donnent aux équipes des outils faciles à utiliser pour s'aligner sur les objectifs. Lorsque les équipes ont une compréhension commune de la portée, s'entendent sur les priorités, planifient plusieurs sprints à l'avance et marquent les histoires de manière appropriée dans leur backlog, les burndowns racontent si la planification et l'exécution sont alignées sur les objectifs. Lorsqu'ils ne le sont pas, ils constituent un outil basé sur les données qui peut alimenter la discussion sur les ajustements nécessaires.