Un burndown chart suit la progression du travail restant au fil du temps.

Dans sa forme la plus simple, il comporte une courbe qui suit l’évolution du travail restant au fil du temps.

Si les choses se passent bien, la courbe devrait diminuer à un rythme régulier jusqu’à zéro. Ainsi, les deux choses à observer dans un burndown sont la tendance de la courbe et l’endroit elle devrait atteindre l’axe des abscisses d’après sa forme globale jusque là.

Un burndown peut inclure une courbe supplémentaire représentant le monde « idéal » où cette ligne diminue uniformément depuis le point de départ jusqu’à à zéro à la fin de la période observée. Si vous souhaitez une courbe de référence plus précise, vous pouvez utiliser les disponibilités de l’équipe.

Pour un sprint, l’axe vertical est la quantité de travail restant, qui peut être le total du reste à faire des tâches ou le total des points des stories restantes. L’axe horizontal est le temps, mesuré en jours.

Ce graphique est très efficace pour inspecter le progrès au regard de l’effort qu’il reste à fournir. Cela peut aider à détecter les problèmes au plus tôt et à supprimer un obstacle ou à adapter le périmètre en conséquence. C’est pourquoi il est inclus dans iceScrum et si largement utilisé dans le monde agile.

Cependant, cela ne fonctionne bien que pour un périmètre prédéfini qui n’est pas destiné à varier de manière significative. C’est très souvent le cas des story points pour un sprint, mais selon votre contexte cela peut ne pas être le cas pour le reste à faire des tâches.

Dans iceScrum, un Burndown est également disponible aux niveaux du projet et de la release sous forme de diagrammes en baton, mais ils sont principalement là pour des raisons historiques car le périmètre d’un projet ou d’une release est en fait voué à varier au fur et à mesure que l’on découvre comment le produit doit évoluer.

Une bonne règle à appliquer : lorsque vous souhaitez utiliser un Burndown mais que le périmètre varie dans le temps, un Burnup chart est probablement un meilleur choix !

Un burnup suit la progression d’un projet jusqu’à son achèvement. Dans sa forme la plus simple le burnup est composé de 2 courbes :

• Une ligne de travail total (la ligne de scope du projet)
• Une ligne de travail fini

L’axe vertical représente la quantité de travail et est mesuré dans une unité personnelle à votre projet (ici, nous avons choisi les points). L’axe horizontal est le temps, mesuré en sprints (d’une semaine).
À chaque sprint, vous pouvez voir la quantité de travail accomplie et la quantité totale de travail. La distance entre les deux lignes est donc la quantité de travail restant. Lorsque les deux lignes se rencontrent, le projet sera terminé. Ceci est une mesure forte pour savoir à quel point vous êtes proche de l’achèvement du projet.

Pourquoi utiliser un burnup ?

L’objectif de tout graphique est la communication. Un graphique de burnup montre clairement le travail accompli et le scope du projet. C’est un outil efficace pour communiquer aux parties prenantes (stakeholders) et aux clients du projet à quel point leurs demandes de fonctionnalités supplémentaires auront une incidence sur la date de fin de projet, et en même temps pour les rassurer sur le fait que des progrès sont réalisés.

Un graphique de flux cumulé est un graphique de zone qui représente la quantité de travail dans un état donné (fini, en cours, planifié, accepté, suggéré, estimé) sur la timeline de votre release, pour chaque sprint et basé sur vos stories. Les lignes se déplacent de haut en bas en fonction du travail accompli au cours de chaque journée / sprint. En un coup d’œil, vous pouvez trouver des informations importantes sur votre projet.

Lorsque les lignes estimé (orange) et fini (vert) se rencontrent, vous pouvez généralement dire que le projet est terminé et le produit livré. En gardant un scope équivalent à ce qu’il est au moment où vous regardez le tableau, vous pouvez imaginer à peu près quand ce croisement se produira. Vous pouvez également avoir une idée du travail en cours sur votre projet en mesurant le nombre de stories entre la ligne verte et la ligne orange. Si vos lignes verte et orange s’éloignent de plus en plus l’une de l’autre, vous pouvez raisonnablement dire que quelque chose ne va pas dans le projet (trop de stories prévues par exemple).

Le graphique de flux cumulé est donc un indicateur très utile pour prendre la température de votre projet en cours, et ce sous plusieurs angles !

Le graphique de parking lot est un graphique centré sur les features qui résume l’état du projet en affichant le taux d’achèvement de chacune de vos features en pourcentage. Chaque pourcentage représente le nombre de stories terminées dans la feature.

Le parking lot regroupe les features en groupes fonctionnels, puis ces groupes en domaines fonctionnels pour mieux illustrer les progrès globaux par rapport aux domaines d’activité.

Le graphique de vélocité affiche la somme des estimations (en points donc) des stories livrées pour chaque sprint. Chaque type de story (d’utilisateur, de défaut et technique) est montré dans cette somme avec un pourcentage et représenté par une couleur différente. Le total est toujours équivalent à 100% car il s’agit du nombre total de points de stories réalisés pendant le sprint.

Ce graphique vous permet donc de voir la vélocité de votre équipe. Une bonne vélocité doit être croissante, c’est-à-dire plus de points obtenus à chaque sprint. Si votre vélocité augmente vous pouvez analyser cette progression en disant que votre équipe est de plus en plus à l’aise avec le projet. Si la vélocité ralentit (généralement c’est assez brutal) c’est généralement dû à des problèmes techniques ou des malentendus dans le projet.

Les couleurs représentent 3 types de stories comme dit précédemment: story d’utilisateur, story technique et story de défaut. Plus vous obtenez de vert dans votre tableau de vélocité, mieux c’est ! En outre, il est préférable d’avoir un graphique de vélocité lentement croissant mais avec seulement des stories d’utilisateur que plus de points avec beaucoup de points de gestion de défauts. En effet, si vous obtenez trop de points sur les stories de défaut, cela signifie que vous passez trop de temps à résoudre les problèmes !

Ce graphique montre la différence entre ce que votre équipe a réalisé lors des sprints précédents (la vélocité de l’équipe, en vert) et ce qui était prévu (en points) à faire par l’équipe (la Vélocité Planifiée de l’équipe, en bleu). La Vélocité Planifiée est la somme des points des stories planifiées dans le sprint au moment de son activation.

Dans une gestion de projet parfaite, les deux lignes doivent se rencontrer à la fin de chaque sprint. Si ce n’est pas le cas, vous pouvez essayer de savoir pourquoi.

Les stories que nous avons réalisées ont peut-être été sous-estimées en termes de points (et / ou de temps) ? Nous avons pris plus de temps pour les atteindre et ne pouvions pas travailler sur les autres, donc elles auraient dû compter plus de points et il devrait y avoir moins de points estimés dans le sprint (signifiant avoir moins de stories dans le plan de sprint). Ou peut-être avons-nous fait face à des problèmes d’équipe comme la maladie ou les départs / arrivées dans l’équipe et cela a affecté la vélocité de l’équipe ?

Quoi qu’il en soit, ce tableau est une autre source d’information utile disponible pour vous dans iceScrum. Et elle vous aidera à améliorer votre gestion de projet !

Vous pouvez utiliser iceScrum pour générer automatiquement des changelogs pour une release ou un sprint. Vous pouvez accéder à cette fonctionnalité à partir de la vue planning, en sélectionnant la release ou le sprint, puis en sélectionnant l’onglet Notes de release ou l’onglet Notes de sprint. Cela affichera toutes les stories incluses dans la période de temps sélectionnée, dans un texte formaté et prêt à copier / coller.

iceScrum fournit un modèle de notes de release et de sprint pour HTML et MarkDown. Nous vous encourageons vivement à les modifier pour répondre à vos besoins ou pour créer vos propres modèles ! Les modèles de notes vous permettent de définir des sections pour différents types de stories, généralement des stories d’utilisateur, de défauts et techniques. Vous pouvez également sélectionner des stories dans une section release / sprint notes en utilisant les tags.

Le champ de modèle de story vous permet de définir quelles informations doivent être incluses dans les notes de release.

Certains champs autorisent l’utilisation de variables afin de rendre le contenu des notes de release dynamique :

• Modèle de story: story information, sprint information, release information, project information
• En-tête: sprint information (seulement pour les notes de sprint), release information, project information
• Pied de page: sprint information (uniquement pour les notes de sprint), release information, project information

${serverUrl} // URL of your icescrum server
${baseUrl} // shortcut for building permalinks = ${serverUrl}/${project.pkey}.
//It can be used as ${baseUrl}-${story.id} to create a permalink to the corresponding story.

${story.id}
${story.name}
// or more generally
${story.[id,
        name,
        description,
        notes,
        origin,
        effort,
        rank,
        affectVersion,
        suggestedDate,
        plannedDate,
        estimatedDate,
        inProgressDate,
        doneDate,
        comments]}

${sprint.id}
${sprint.goal}
// or more generally
${sprint.[id,
          goal,
          startDate,
          velocity,
          plannedVelocity,
          endDate,
          deliveryVersion,
          orderNumber,
          index]}

${release.id}
${release.name}
// or more generally
${release.[id,
           name,
           startDate,
           endDate,
           orderNumber]}

${project.id}
${project.name}
// or more generally
${project.[id,
           name,
           pkey,
           description,
           startDate,
           endDate]}

La génération de notes de releases et de sprints sont également disponibles via les API Web iceScrum, de sorte que vous pouvez automatiser votre processus de release !

Consultez la section correspondante dans la documentation de l’API.