Le « Burndown chart » est bien connu des équipes de développement agiles.
Si vous avez plutôt l’habitude des méthodologies de gestion de projet traditionnelles, du type cycle en V ou modèle en cascade, vous êtes sans doute plus familier/ère du diagramme de GANTT, un incontournable quand il s’agit de suivre l’avancement des différentes activités et tâches qui constituent un projet.
Dans cet article, je vous propose de nous attarder sur un autre outil de planification, cette fois-ci adapté à la gestion de projet agile : le Burndown Chart.
Ce graphique simple aide à contrôler la livraison des incréments de produit dans les délais souhaités, en affichant l’effort fourni et à fournir (les « story points ») par jour sur toute la durée du sprint.
Bien que nous, Business Analysts, n’ayons pas à compléter le Burndown Chart, ce diagramme est important à connaître si nous faisons partie d’une équipe agile réalisatrice du logiciel cible. En effet, à ce titre, nous sommes solidairement engagé(e)s à respecter les délais que l’équipe s’est fixés.
Le Burndown Chart: késako?
Comprendre le Burndown Chart, c’est être en mesure de mieux anticiper l’effort à fournir en business analyse et ne plus se laisser surprendre par des délais irréalistes, que l’on a acceptés par simple méconnaissance des outils agiles.
[Formation] Comment être rapidement opérationnel
Business Analyst en Systèmes d'Information DEBUTANT
2 heures de conseils pratiques pour identifier les informations initiales à recueillir, bâtir une première feuille de route claire de vos activités, et produire vos tous premiers résultats.
Un document utilisé en gestion de projet agile
Pour comprendre à quoi servent les “Burndown” charts, il est nécessaire d’appréhender certains des principes-clé de la gestion de projet Agile.
En effet, si l’agilité est avant tout un état d’esprit dont les piliers ont été décrits dans le Manifeste agile, elle a également conduit à l’élaboration et à l’utilisation de différentes approches et cadres méthodologiques, dont le plus utilisé est SCRUM. Comme son nom l’indique, l’agilité est une façon de gérer des projets de manière flexible, ciblée et réactive.
Bien que les objectifs soient toujours clairement définis, les équipes agiles sont plus autonomes et moins dirigées par leur chef de projet que les équipes de développement traditionnelles. Les exigences du produit sont souvent définies juste avant le début du développement d’une fonctionnalité, l’accent est mis sur les tests utilisateurs, le feedback terrain des utilisateurs finaux, ainsi que sur l’évaluation et la réévaluation constantes de la portée et de l’objectif d’un produit.
Comprendre le jargon agile
Les « sprints »
Les équipes de développement agiles travaillent normalement par courtes périodes appelées itérations ou “sprints“, durant généralement entre deux et quatre semaines. Chacun de ces sprints a pour objectif l’accomplissement de progrès tangibles (plutôt que la rédaction de documentation fonctionnelle ou technique), souvent en développant des versions opérationnelles d’un produit ou d’un logiciel.
Les « user stories »
Pour planifier leur travail sur les sprints à venir, les équipes de développement agiles se basent essentiellement sur l’utilisation de “User Stories“. Cela leur permet de visualiser ce qui est nécessaire et comment le réaliser du point de vue de l’utilisateur final.
Les « tableaux Kanban »
Pour cadencer l’évolution du travail, les équipes utilisent également les événements (réunions, “cérémonies”) Scrum et les tableaux de type Kanban.
Les tableaux Kanban sont un moyen de montrer visuellement l’état d’avancement des incréments du produit devant être livrées pendant le sprint.
Les « scrum meetings »
Les « daily scrum meetings », par exemple, sont des réunions rapides, de type stand-up, qui se tiennent normalement quotidiennement pendant maximum 15 minutes. Elles permettent aux équipes de collaborer, d’écouter et de discuter des progrès, des réalisations, ainsi que des obstacles et de la manière dont elles peuvent s’entraider pour dépasser ces derniers.
[Master Class] Devenir Business Analyst en S.I.
Les Fondamentaux de A à Z
50 heures de formation qualifiante complète en e-learning pour se professionnaliser au métier de Business Analyst en systèmes d'information.
Le Burndown Chart : un indicateur de mesure du RAF (reste à faire)
Les Burndown Charts sont un outil visuel qui peuvent être utilisés parallèlement aux réunions Scrum ou aux tableaux Kanban. Ils ont été inventés par Ken Schwaber (l’un des leaders du mouvement agile) en 2000, afin de donner aux équipes un moyen simple de représenter l’effort restant à fournir sur un projet, par rapport au reliquat de temps disponible sur le(s) sprint(s).
Les caractéristiques du Burndown Chart
Sur l’axe X du graphique s’affiche le nombre de jours que dure le sprint. Sur l’axe Y s’affiche l’effort en terme de story-points (ou de tickets) de l’équipe.
On y voit également deux courbes : l’une représente le niveau de progression idéal, l’autre le niveau de progression réel de l’équipe. La courbe de progression idéale sert de point de référence à l’équipe Scrum. C’est là où elle devrait être à un moment précis du projet, en fonction de l’effort qu’elle a elle-même estimé avant de commencer le sprint.
Lorsque la courbe de progression réelle est au-dessus de la courbe de référence idéale, cela signifie que l’équipe n’a pas rempli son engagement. Il a pu y avoir des problèmes techniques, de manque de disponibilité, de maladie, des bugs à traiter d’urgence ou autres tâches rajoutées par le Product Owner.
Ces tâches, dont l’effort est estimé en points (d’où le nom de « Story Points » pour l’axe Y du graphique), modifient de facto le périmètre du sprint et des suivants, puisque les tâches non terminées mais prévues sont décalées dans le prochain sprint.
L’interprétation de la courbe de progression
Lorsque la courbe de progression réelle est au-dessous de la courbe de référence idéale, cela signifie que l’équipe a dépassé son engagement prévisionnel. Cela peut être une bonne nouvelle, bien sûr, mais cela peut aussi être un point d’attention signalant que l’équipe estime mal l’effort à fournir sur ses tâches, et que celle-ci aurait en réalité la capacité à développer plus de fonctionnalités dans le temps imparti du sprint.
Exemple de création et d’utilisation d’un Burndown Chart
La mesure de la progression réalisée au travers du Burndown Chart dépend de la nature du projet, de la composition et des compétences de l’équipe de développement agile.
Imaginons un projet agile dont les délais sont très serrés. La cheffe de projet côté maîtrise d’œuvre (MOE) doit suivre l’avancement quotidiennement de son équipe Scrum agile.
Préparation du Burndown Chart
Chaque matin à 9h, elle tient donc le « daily scrum meeting », courte réunion en stand-up durant laquelle les membres de l’équipe discutent de ce qui doit être réalisé dans le Sprint en cours, de leurs obstacles et contraintes pouvant retarder le reste à faire.
Les tâches à réaliser sont estimées sous forme de « story points », qui indiquent le temps et l’effort nécessaires à leur réalisation. C’est l’équipe elle-même qui évalue cet effort, lequel vaut engagement solidaire.
L’équipe utilise un tableau Kanban pour gérer le déroulement du projet et le met à jour après chaque réunion Scrum, en indiquant notamment le nombre de « story points » réalisés ce jour-là.
Création du Burndown Chart
Pour créer son Burndown Chart, la cheffe de projet indique tout d’abord, sur l’axe Y, le nombre de story point, et fait figurer sur l’axe horizontal X le nombre de sprints.
Sur cet exemple fictif, l’effort global de départ estimé par l’équipe est de 240 « story points ». L’objectif étant de terminer le projet en six itérations de 15 jours chacune (sprints), cela donne une moyenne de 40 story points par sprint. Si l’équipe y parvient, le graphique montrera simplement une ligne droite diagonale descendant de 240 au début du projet, à 0, à l’issue des 6 sprints.
Analyse du Burndown Chart
Dans la réalité, bien sûr, les projets se déroulent rarement de façon linéaire et aussi bien que cela.
C’est là qu’un Burndown Chart peut s’avérer utile. La figure ci-dessous, montre la progression réelle au fil des sprints de l’équipe Agile.
Le graphique montre que les choses se sont bien déroulées au cours des deux premiers sprints, la courbe réelle en jaune étant en-dessous de la courbe de référence en blanc. En revanche, on voit que le nombre de story points à réaliser a brutalement augmenté entre la deuxième et la troisième itération, avant de reprendre une belle progression à partir du 3ème sprint.
L’analyse du Burndown Chart peut démontrer plusieurs raisons à cela : un collaborateur clé de l’équipe agile était malade, les users stories à développer se sont avérées plus difficiles ou complexes que prévu (tant sur le plan technique, de l’architecture, des règles métiers ou autre), ou encore, le Product Owner a modifié la portée du produit.
Une représentation graphique très utile
Vous l’avez compris dans cet exemple : l’intérêt du Burndown Chart est d’une part, d’avoir pu constater rapidement que la progression du projet / produit a été retardée, et d’autre part, que cela ait permis de prendre les mesures appropriées de manière collégiale et consensuelle.
Un outil nécessaire mais insuffisant
Visuel, simple et efficace
Le principal avantage des Burndown Charts est leur simplicité : ils constituent une représentation visuelle facile à suivre par l’équipe Agile afin qu’elle se rende compte d’un seul coup d’œil ce qu’il lui reste à réaliser et si elle est en capacité à respecter ses échéances.
Cela permet d’alerter rapidement de tout problème ou goulot d’étranglement potentiel. Par exemple, si la courbe de progression réelle montre un plateau, cela indique que les collaborateurs doivent accentuer leurs efforts.
C’est également un excellent outil de motivation, qui montre à l’équipe ce qu’il lui reste à faire, mais aussi dans quelle mesure elle a déjà réussi pas mal de choses !
A utiliser en complément d’autres outils de gestion de projet
Un Burndown Chart est en revanche insuffisant. Il ne montre que le travail terminé, et non la tâche ou la user story en cours, ni, non plus, si on est proche ou loin de la fin du travail de développement.
Ces éléments sont par exemple abordés lors des Scrum meetings. Quoi qu’il en soit, cela met bien en lumière qu’un Burndown Chart ne fournit qu’une partie de l’information et qu’on ne peut se reposer à 100% dessus pour gérer l’avancement du projet agile.
Autre lacune ou biais de ce type de diagrammes : ils peuvent conduire à des attentes trop élevées. Instinctivement, on a envie de voir une courbe de progression suivant une belle ligne droite (comme sur la première figure).
Un chef de projet ou une équipe inexpérimentée pourrait donc être tenté de gérer « agressivement » les performances à atteindre, et de céder à certains biais cognitifs visant à « bidouiller » l’effort à consentir pour coller à cette courbe idéale.
Attention donc à ne pas provoquer des effets de bord sur le moral de l’équipe, qui pourrait se démotiver ou être mécontente, ou ne pas avoir l’impression d’être écoutée.
Il arrive souvent que la progression arrive à un plateau au milieu d’un projet, lorsque les éléments les plus complexes sont achevés, puis une accélération vers la fin. Avoir conscience de ce phénomène et en tenir compte est important pour prendre les bonnes décisions en matière de gestion de projet.
Points clés
Les Burndown Charts offrent une représentation visuelle simple de l’état d’avancement d’un projet.
Ils sont couramment utilisés dans le cadre de la gestion de projet Agile dont ils permettent de mesurer la progression en comparant les tâches à accomplir au temps disponible pour les réaliser.
Ils peuvent être un outil puissant pour montrer le travail accompli et le reste à faire sur la durée des sprints, mais ils sont insuffisants pour donner une image claire du travail en cours ou en voie d’achèvement.
En tant que Business Analyst, comprendre le Burndown Chart est important car nous pouvons ainsi collaborer activement à l’estimation de l’effort à fournir sur les sprints à venir, et ne pas subir des attentes que nous estimerions irréalistes.
