Les Reportings Agile de Jira Software

Jira Software propose une gamme de rapports qui vous permettent de visualiser les tendances concernant votre projet, ses versions, ses epics, ses sprints et ses tickets.

Dans ce qui suit, sont détaillés un ensemble de rapports Agile permettant de :

comprendre la vélocité de l’équipe,
identifier les goulots d’étranglement
prédire les performances futures

Burdown Chart

Le Burndown Chart montre la quantité réelle et estimée de travail à effectuer dans un sprint. L’axe X horizontal dans un graphique Burndown indique le temps et l’axe Y vertical indique les tickets.

Le Burndown Chart permet de suivre le travail total restant et d’estimer les chances d’atteindre l’objectif du sprint. En suivant le travail restant tout au long de l’itération, une équipe peut gérer sa progression et réagir aux tendances en conséquence. Dans le cas où le graphique de progression indique que l’équipe pourrait ne pas atteindre l’objectif du sprint, l’équipe peut mettre en place les actions requises pour maintenir le cap.

Le Burndown Chart s’applique uniquement aux tableaux Scrum.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Burndown Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

Statistique d’estimation : l’axe vertical représente la statistique d’estimation sélectionnée.
Valeurs restantes : la ligne rouge représente la quantité totale de travail restant dans le sprint, selon les estimations de votre équipe. Quand la quantité de travail augmente lors d’un sprint suite à l’ajout de nouvelles user stories ou la revue à la hausse de l’estimation de user stories, la ligne rouge évolue vers le haut.
Guide : la ligne grise montre approximativement où votre équipe devrait se trouver (avec un avancement linéaire). Si la ligne rouge est en dessous de cette ligne, votre équipe est sur la bonne voie pour terminer tout son travail à la fin du sprint. Cette information n’est toutefois pas infaillible ; il s’agit simplement d’une information à utiliser tout en surveillant l’avancement de l’équipe.
Les zones grisées représentent les jours non travaillés

Burnup Chart

Le burnup chart fournit une représentation visuelle du travail accompli lors d’un sprint par rapport à son périmètre. Il offre des informations sur la progression de votre projet, ainsi que des avertissements pour vous aider à maintenir la santé de votre projet ; vous pouvez instantanément repérer des problèmes tels que le dépassement du périmètre initialement prévue ou une déviation par rapport au chemin de projet planifié.

Alors que le Burndown Chart indique le reste de travail à accomplir dans le sprint, le Burnup chart montre le travail réalisé et le total du travail à faire.

Le Burnup Chart s’applique uniquement aux tableaux Scrum.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Burnup Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

L’axe vertical représente la quantité de travail et peut être mesuré de différentes façons telles que les story points, le nombre de tâches ou les estimations. L’axe horizontal représente le temps en jours.
Le périmètre du travail (la ligne rouge) montre le travail qui était prévu pour le sprint. Si cette ligne augmente au cours du sprint, c’est un signe de débordement du périmètre initial.
Le travail achevé (la ligne verte) montre le travail qui a été réalisé.
La ligne directrice (la ligne grise) est une ligne théorique montrant l’achèvement quotidien nécessaire pour respecter la date limite.
La distance entre le périmètre du travail (la ligne rouge) et le travail achevé (la ligne verte) sur le graphique représente la quantité de travail restante. Lorsque tout le travail du sprint est achevé, les lignes se rejoignent.
Les pics dans le périmètre du travail signifient qu’un élément a été ajouté à la tâche, tandis que les pics dans le travail achevé signifient qu’une story a été réalisée. Ces informations peuvent être cruciales lors de la rétrospective pour comprendre si, par exemple, trop de travail a été ajouté ou si le travail a été plus complexe que prévu.
Examinez la ligne ‘Périmètre du travail’ pour identifier tout débordement du périmètre initial.
Si l’estimation n’a pas été activée, votre rapport s’affichera en utilisant le nombre de tâches, ce qui signifie qu’elles seront traitées comme ayant le même poids.

Sprint Report

Le Sprint report affiche la liste des tâches pour chaque sprint. Il est utile pour les réunions de Rétrospective de Sprint, ainsi que pour lors des points relatifs à l’état d’avancements du sprint.

Si votre instance Jira Software est connectée à Confluence, il est possible de créer les pages de rétrospective confluence à l’aide du bouton “Associer une page Confluence”

Le Sprint report s’applique uniquement aux tableaux Scrum.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Sprint report Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

Le Sprint Report est spécifique au tableau – il ne comprendra que les tâches correspondant au filtre enregistré de votre tableau.
Sous le rapport, les tâches du sprint sont répertoriées en fonction de leurs états d’avancement. Sous « Tâches Terminées », la colonne « Story Points » indique combien de Story Points votre équipe a réalisé pendant le sprint. Si elle est affichée avec deux valeurs et une flèche entre elles (par exemple 3 → 3.5), cela indique qu’une estimation de Story Points a été revue pendant le sprint.
Les tâches ajoutées après le début du sprint sont indiquées par un astérisque.
Une tâche est considérée comme « À Faire » lorsqu’elle est dans un statut qui est associé à la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminée » lorsqu’elle se trouve dans un statut qui est associé à la colonne la plus à droite de votre tableau. Voir la configuration des colonnes pour plus d’informations.
La ligne grise représente une ligne directrice qui va du total estimé des tâches au début du sprint à 0 à la fin du sprint. La ligne grise reste horizontale pendant les jours non travaillés.
La ligne rouge représente le travail réel effectué pendant le sprint – elle est tracée à partir de l’estimation totale des tâches au début du sprint, et elle monte ou descend à mesure que votre équipe travaille sur les tâches du sprint. Notez que la ligne rouge montre l’estimation totale actuelle pour les tâches non résolues à n’importe quel moment du sprint. Elle reflète également les tâches qui sont ajoutées ou retirées du sprint.
Si votre tableau est configuré pour suivre les estimations restantes et le temps passé, une ligne verte s’affichera dans le Rapport de Sprint, indiquant le travail enregistré sur les tâches.

Velocity Chart

Le Velocity Chart est la quantité moyenne de travail qu’une équipe Scrum effectue au cours d’un sprint, mesurée en Story Points ou en heures, et est très utile pour les prévisions. Le product owner peut utiliser la vélocité pour prédire la rapidité avec laquelle une équipe peut traiter la backlog, car le rapport suit le travail prévu et terminé sur plusieurs itérations : plus il y a d’itérations, plus la prévision est précise.

Le Volocity Chart n’est applicable que dans le cadre d’un modèle projet Scrum.

Statistique d’estimation : l’axe des Y affiche la statistique utilisée pour estimer les storys. En savoir plus sur la configuration de l’estimation et du suivi. Les estimations peuvent être basées sur :
- Story points, comme le montre l’exemple ci-dessus
- Temps estimé (minutes, heures, jours ou semaines)
- le nombre de tâches
- Tout champ numérique personnalisé dans Jira.
Engagement : la barre grise de chaque sprint affiche l’estimation totale de toutes les tâches au début du sprint. Une fois le sprint lancé, les story ajoutées au sprint ou les modifications apportées aux estimations ne seront pas incluses dans ce total.
Terminé : la barre verte de chaque sprint affiche le total des estimations terminées à la fin du sprint. Toutes les modifications du périmètre apportées après le démarrage du sprint sont incluses dans ce total.
Sprints : L’axe des X affiche les 7 derniers sprints réalisés par l’équipe. Ces données sont utilisées pour calculer la vitesse.

Autres points à noter concernant le Velocity Chart :

Il est spécifique au bord, ce qui signifie qu’il n’inclura que les tâches du filtre associé au bord.
Il est basé sur le mapping des colonnes de votre tableau. Une tâche est considérée comme « À faire » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.

Calcul de la vélocité
La vélocité récente d’une équipe peut être utile pour aider à prédire la quantité de travail qui peut être accomplie par l’équipe lors d’un prochain sprint. La vélocité est calculée en prenant la moyenne des estimations totales réalisées au cours des derniers sprints.

Cette valeur devrait devenir plus précise et fiable au fil du temps, à mesure que davantage de données deviennent disponibles et que l’équipe s’améliore dans l’estimation des tâches.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Velocity Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

Cumulative Flow Diagram

Un Cumulative Flow Diagram (CFD) est un graphique en aires qui montre les différents statuts des éléments de travail pour une application, une version ou un sprint. L’axe horizontal des X dans un CFD indique le temps et l’axe vertical des Y indique les tâches. Chaque zone colorée du graphique équivaut à un statut de flux de travail (c’est-à-dire une colonne sur votre tableau).

Le CFD peut être utile pour identifier les goulots d’étranglement. Si votre graphique contient une zone qui s’élargit verticalement au fil du temps, la colonne qui équivaut à la zone qui s’élargit constituera généralement un goulot d’étranglement.

Le CFD est spécifique au bord, c’est-à-dire qu’il inclura uniquement les tâches qui correspondent au filtre enregistré de votre bord.

Il est basé sur le mapping des colonnes de votre bord. Une tâche est considérée comme « À faire » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.

Il garde une trace du nombre de tâches qui transitent par chaque colonne de votre bord, vous aidant ainsi à voir quelles colonnes accumulent plus de problèmes que d’autres.

Par exemple:

Si vous démarrez un sprint avec 5 tickets, tous les tickets commenceront dans la colonne To Do. Si vous consultez le CFD, il affichera 5 tâches à faire, 0 tâche en cours et 0 tâche terminé.

Si vous déplacez ensuite 2 tâches vers En cours, le CFD affichera 5 tâches À faire (car 5 sont passés par cette colonne), 2 tâches En cours et 0 tâcheTerminé.

Si vous déplacez ensuite 1 tâche de En cours à Terminé, le CFD affichera À faire = 5, En cours = 2 et Terminé = 1.

Si vous retirez ensuite cette tâche de Terminé et la remettez dans À faire, le CFD supprimera le 1 de Terminé et supprimera 1 de En cours, mais les chiffres dans À faire resteront les mêmes, car aucune nouvelle tâche n’est arrivée. . Par conséquent, le CFD affichera À faire = 5, En cours = 1, Terminé = 0.

Version Report

Le Version Report montre la progression de votre équipe vers l’achèvement d’une version. Le Version Report vous indique également la date de release prévue, en fonction du taux de progression (vélocité) moyen de votre équipe depuis le début de la version, et de la quantité estimée de travail restant.

Le Version Report est spécifique au bord – c’est-à-dire qu’il inclura uniquement les tâches qui correspondent au filtre enregistré de votre bord.
Le Version Report exclura les tâches d’un « type de sous-tâche ».
Le Version Report affiche les versions « Released» mais pas les versions « Archivées ».
Le Version Report est basé sur le mapping des colonnes de votre tableau. Une tâche est considérée comme « À faire » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.
L’axe horizontal commence à la date de début de la version ; ou si aucune date de début n’est spécifiée, la date à laquelle une tâche a été ajoutée pour la première fois à la version. Le graphique montre l’état dans lequel se trouvait votre version à un moment donné, en termes de vos Story Points totaux et complétés (ou d’autres statistiques d’estimation de votre choix), afin que vous puissiez voir comment le périmètre a pu changer et comment vous progressez vers l’achèvement des travaux estimés.
la ligne rouge représente le pourcentage des tâches non encore estimées
Le graphique vous montre les prédictions suivantes :
- la date de sortie prévue (ligne bleue) – c’est-à-dire la date à laquelle vous pouvez vous attendre à ce que toutes les tâches de votre version soient terminées, en fonction de votre vélocité quotidienne moyenne et de la quantité de travail restante estimée.
- la date de sortie prévue (optimiste) (zone ombrée à gauche de la ligne bleue) – c’est-à-dire la date la plus proche à laquelle vous pouvez vous attendre à ce que la version soit complète. (La date « optimiste » est calculée en ajoutant 10 % à la vélocité quotidienne moyenne.)
- la date de sortie prévue (pessimiste) (zone ombrée à droite de la ligne bleue) – c’est-à-dire la dernière date à laquelle vous pouvez vous attendre à ce que la version soit complète. (La date « pessimiste » est calculée en soustrayant 10 % de la vélocité quotidienne moyenne.)
10 % du travail estimé pour la version devra être terminé avant que les prédictions puissent être calculées.

Epic Report

Le Epic Report affiche une liste des tâches complètes, incomplètes et non estimées dans une Epic. Il est particulièrement utile pour planifier le travail d’une Epic pouvant s’étendre sur plusieurs sprints.

Utilisez le Epic report pour comprendre la progression vers la réalisation d’une Epic au fil du temps et pour suivre la quantité de travail restant incomplet ou non estimé.

Le Epic Report est basé sur le mapping des colonnes de votre tableau. Une tâche est considérée comme « À faire » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.
Le graphique sera différent si vous utilisez le nombre de tâches comme statistique d’estimation (plutôt que les Story Points, comme indiqué dans la capture d’écran ci-dessus).
Le graphique indique :
- le nombre total de story points
- le nombre total de story points « Terminé »
- le nombre total de tâches
- le nombre total de tâches non estimées

Control Chart

Le Control Chart affiche le temps de cycle (ou délai de livraison) de votre produit, version ou sprint. Il prend le temps passé par chaque tâche dans un ou plusieurs statuts particuliers et le mappe sur une période de temps spécifiée. La moyenne, la moyenne mobile et l’écart type de ces données sont affichés.

Le Control Chart vous aide à identifier si les données du sprint en cours peuvent être utilisées pour déterminer les performances futures. Moins la durée de cycle d’une tâche varie, plus la confiance dans l’utilisation de la moyenne comme indication des performances futures est élevée.

Quel est le temps de cycle et le délai de livraison ?

Le temps de cycle est le temps passé à travailler sur une tâche – généralement le temps écoulé entre le début du travail sur une tâche et le moment où le travail est terminé, mais il inclut également tout autre temps passé à travailler sur la tâche. Par exemple, si une tâche est rouverte, traitée et terminée à nouveau, le temps nécessaire à ce travail supplémentaire est ajouté au temps de cycle.

Le délai de livraison est similaire au temps de cycle, mais il s’agit du temps écoulé entre le moment où une tâche est créée (et non le moment où le travail commence) jusqu’à ce que le travail soit terminé sur cette tâche.

Comment est déterminé le temps de cycle ?

Les statuts utilisés pour calculer le temps de cycle dépendent du workflow que vous utilisez pour votre projet. Vous devez configurer le Control Chart pour inclure les statuts qui représentent le temps passé à travailler sur une tâche. Notez que le Control Chart tentera de sélectionner ces statuts automatiquement.

Par exemple, si vous utilisez le workflow « Jira Software Development », vous pouvez considérer que le travail a commencé sur une tâche lorsqu’elle passe à « En cours », et que le travail est terminé lorsqu’elle passe de « En révision » à « Terminé ». ‘. Vous l’afficherez sur le Control Chart en sélectionnant « En cours » et « En révision » comme colonnes, car cela afficherait le temps passé par les tâches dans ces deux statuts.

Comment est calculée la moyenne mobile ?

La moyenne mobile (ligne bleue sur le graphique) est basée sur la tâche et non sur le temps. Pour chaque tâche affichée sur le graphique, la moyenne mobile (à ce moment-là) est calculée en prenant la tâche elle-même, X tâches avant la tâche et X tâches après la tâche, puis en faisant la moyenne de leurs temps de cycle. 20 % du total des tâches affichées (toujours un nombre impair et un minimum de 5 tâches) est utilisé dans le calcul.

Que représente la zone ombrée en bleu ?

La zone ombrée en bleu du Control Chart représente l’écart type, c’est-à-dire l’ampleur de la variation des données réelles par rapport à la moyenne mobile.

L’écart type vous donne une indication du niveau de confiance que vous pouvez avoir dans les données. Par exemple, s’il existe une bande bleue étroite (faible écart type), vous pouvez être sûr que le temps de cycle des émissions futures sera proche de la moyenne mobile.

Que représentent les points sur le graphique ?

Chaque point vert représente une tâche ou un groupe de tâches :

L’emplacement vertical du point représente le temps de cycle de la tâche, c’est-à-dire le « Temps écoulé ». Pour un groupe de tâches, le point est placé au niveau du temps de cycle moyen des tâches.

Le placement horizontal indique le moment où le ou les tâches sont sorties du dernier statut sélectionné sur le graphique (en colonnes).

Exemples de control chart :

Sur ce premier exemple :

La productivité de l’équipe augmente : comme l’indique la tendance à la baisse de la moyenne mobile.
La durée de cycle des tâches futures sera probablement proche de la moyenne mobile (2 jours ou moins) : indiquée par le faible écart type (zone étroite ombrée en bleu).

Sur ce deuxième exemple :

La productivité de l’équipe est assez constante : indiquée par une moyenne mobile proche de la moyenne.
Il existe des valeurs aberrantes évidentes les mardi 14 et mercredi 15 (respectivement 7 jours et 10 jours de temps écoulé, contre 2 jours en moyenne) qui devraient faire l’objet d’une analyse.
Les données deviennent de plus en plus prévisibles au fil du temps.

Epic Burndown

Le rapport Epic Burndown vous montre comment votre équipe progresse par rapport au travail d’une Epic. Une Epic est un chantier regroupant plusieurs User story. Le rapport affichera des données basées sur la statistique d’estimation utilisée au niveau du bord.

L’Epic Burndown permet de :

Voir à quelle vélocité votre équipe travaille sur l’Epic,
Découvrir comment le travail ajouté et supprimé pendant le sprint a affecté la progression globale de l’équipe
Prévoir le nombre de sprints nécessaires pour terminer le travail d’une Epic, en vous basant sur les sprints passés et les changements au cours des sprints.

Le graphique affiche les informations suivantes :

Section vert clair = travail réalisé pendant le sprint. Si une barre est entièrement vert clair, vous ne pourrez pas dire quelle part du travail effectué était initialement estimée ou non. Pour connaître ces informations, cliquez sur la barre pour afficher les détails.
Section bleu clair = travail restant dans l’Epic par rapport à l’ensemble du travail estimé pour l’Epic au début du sprint.
Section bleu foncé = travail ajouté pendant le sprint, mais non inclus à l’origine (c’est-à-dire changement de périmètre).
Section vert clair + section bleu clair = travail total dans l’Epic initialement estimé au début du sprint.
Section bleu clair + section bleu foncé = travail total dans l’Epic restant à la fin du sprint.
Barres avec sections grises = sprints prévus. Les sprints prédits sont calculés en fonction de la vélocité de votre équipe (quantité de travail effectué au cours des trois derniers sprints) et du travail total restant pour l’Epic. Le changement de périmètre n’est pas pris en compte lors du calcul de la vélocité, mais est inclus dans le travail total restant.

Release Burndown

Le Release Burndown report vous montre comment votre équipe progresse dans le travail d’une Release. Dans Jira Software, il n’y a pas d’élément appelé « Release » : une version équivaut à une release (par conséquent, le terme « version » sera utilisé à la place de « release»). Le rapport affichera des données basées sur la statistique d’estimation utilisée par votre bord.

A l’instar de l’Epic Burndown, le Release Burndown permet de :

Voir à quelle vélocité votre équipe travaille sur la Release,
Découvrir comment le travail ajouté et supprimé pendant le sprint a affecté la progression globale de l’équipe
Prévoir le nombre de sprints nécessaires pour terminer le travail d’une Release, en vous basant sur les sprints passés et les changements au cours des sprints.