Les rapports Jira pour booster les projets agiles (Scrum, Kanban)

En agile Scrum ou Kanban, un des besoins fondamentaux est de mesurer les performances. Jira Software propose une fonctionnalité pertinente : les rapports. En effet, l’Inspection, c’est-à-dire la mesure d’un certain nombre d’indicateurs ou de métriques est un des trois piliers de la méthode agile (à lire aussi les articles sur les mesures de l’agilité).

Jira propose des rapports intégrés, mais peu de gens les utilisent faute de les maîtriser.
Et pourtant, les rapports Jira contiennent des informations précieuses et même indispensables pour les équipes. Et il est tout à fait possible d’accéder à ces données. Nous rappelons trois conditions fondamentales pour une utilisation optimale :

  1. Il faut bien identifier à qui s’adressent les rapports
  2. Il faut bien analyser les informations qu’ils donnent
  3. Il faut bien renseigner certaines données dans votre travail au quotidien, car c’est sur ces données que se basent les rapports

À qui s’adressent les rapports Jira ?

Les rapports Jira ne sont pas destinés à la direction de l’entreprise, et ne peuvent pas être utilisés pour définir la stratégie. Ils ne servent pas non plus pour la planification à long terme, ni pour l’analyse des interdépendances entre les projets. L’éditeur logiciel Atlassian propose par ailleurs des outils dédiés à ces usages (par exemple, Advanced Roadmaps, ou encore Jira Align).

Les rapports Jira sont destinés aux équipes Projet. Ils s’adressent à l’ensemble de l’équipe agile : Product Owner, développeurs et Scrum Master. Ces 3 rôles ont pour objectif de suivre l’avancement du projet et l’adapter au besoin. Les rapports Jira ainsi aident l’équipe à suivre ce qui est fait et ce qui reste à faire. C’est une photo du projet à l’instant « T ». Cet ensemble d’informations doit être analysé par l’équipe pour en assurer l’amélioration continue.

Quelles informations trouve-t’on dans les rapports Jira ?

Les rapports Jira Software sont étroitement liés aux tableaux de suivi de projet agile et de leur paramétrage (filtres). Par exemple, si vous avez 3 tableaux distincts, un pour l’équipe A, un autre pour l’équipe B et un troisième, multi-équipe, pour le suivi des bugs, vous aurez des rapports très différents dans ces 3 tableaux.

Par ailleurs, vous n’obtiendrez pas les mêmes rapports en fonction du type de tableau agile Scrum ou Kanban, l’échelle de temps étant très différente entre ces deux tableaux. Dans la méthode Scrum, la contrainte temporelle est plus rythmée du fait des Sprints, contrairement au Kanban. Les rapports Scrum seront plus nombreux car ils seront soumis à cette contrainte.

Voici un exemple de rapport Kanban :

Cumulative Flow Diagram

Le diagramme montre les statuts des demandes à travers le temps. Ce rapport aide surtout à identifier les goulots d’étranglement éventuels.

Dans ce rapport, on distingue le nombre total de demandes (plus de 1000), classées en fonction de leurs statuts. Plus de 700 demandes sont terminées, 200 restent à adresser.

Par ailleurs, on voit qu’il s’agit d’un projet long avec un effectif réduit. En effet, le nombre de demandes en cours (« In Progress ») et en test (« In Test ») est bien inférieur à ce qui reste à faire. En revanche, il n’y a pas de goulot d’étranglement sur le projet : le nombre de requêtes « In Progress » et « In Test » reste stable.

Ce rapport peut être affiné en fonction du temps, des statuts et de filtres rapides.

Exemples de rapports Scrum

Les rapports disposent des mêmes fonctionnalités lorsqu’on utilise des tableaux Scrum.

Rapport de Sprint

Voici deux exemples de rapports Jira de Sprint. Le premier correspondrait au rapport presque “idéal”. Le deuxième représente ce qu’on trouve souvent chez les utilisateurs de Jira.

Dans les rapports, la courbe grise indique la quantité de travail estimée, la courbe rouge le travail réalisé. L’axe horizontal du graphique représente le temps, alors que l’axe vertical hiérarchise la valeur des demandes.

Sous le graphique, on trouve le détail du Sprint, à savoir :

  • Les demandes terminées
  • Les demandes en cours
  • Les demandes sorties du Sprint
  • Les demandes ajoutées au cours du Sprint
  • Les demandes pour lesquelles l’estimation a été modifiée

Pourquoi le premier exemple de rapport Jira est-il “idéal” ? La courbe de réalisation suit presque parfaitement la courbe prévisionnelle. L’équipe a même parfois été en avance. Toutes les User Stories, exceptée une, ont été réalisées durant le Sprint. Le seul bémol dans ce rapport est que la priorité est la même pour toutes les demandes, ce qui est impossible en réalité – il y a toujours des demandes plus prioritaires que d’autres.

Le deuxième exemple montre un Sprint beaucoup plus mouvementé. Le graphique appelé Burndown chart indique que :

  • La moitié des demandes planifiées n’ont pas été réalisées (les courbes rouges et grises ne se rejoignent pas à la fin)
  • Les demandes non prévues ont été rajoutées en cours de sprint (identifiées sur la liste avec une étoile) et la courbe rouge repart vers le haut
  • L’estimation de certaines demandes a été modifiée (ce qui est montré par dans la liste par les flèches) :
  • Seule une partie des Bugs apparaît sous forme de nouvelle demande. Par principe, les Bugs ne devraient pas apparaître (ils n’apportent aucune valeur ajoutée et représentent, au contraire, une dette technique). Cependant, si l’équipe décide d’estimer les Bugs, elle doit rester cohérente et estimer tous les Bugs sans exception

Comment mieux utiliser les rapports Jira Software ?

Trois points doivent être vérifiés :

  1. Pour les rapports Scrum et Kanban, il y a une subtilité qui concerne la résolution des demandes. Dans un tableau, une demande est considérée comme étant terminée quand elle se trouve dans la dernière colonne, même si le champ « Résolution » est rempli. Ce point est essentiel.
  2. Utilisez les filtres pour affiner vos rapports.
  3. Pour les tableaux Scrum :
    • a. Divisez bien votre Backlog en User Stories pour obtenir le niveau de détail nécessaire
    • b. Estimez chacune des User Stories ou, à minima, paramétrez votre tableau pour compter le nombre de Stories. Cela est nécessaire pour les rapports de Sprint, ainsi que pour le Velocity Chart
    • c. Positionnez les Stories sur le Sprint avant d’exécuter le rapport
    • d. Maintenez la durée fixe des Sprints
    • e. N’attendez pas le jour de la Sprint Review pour faire avancer les Stories
    • f. Utilisez les Epics et les Versions pour pouvoir faire des prévisions

Conclusion : n’attendez pas pour utiliser les rapports agiles de Jira

Les rapports de Jira offrent un moyen très simple et peu couteux d’obtenir des indicateurs précieux sur l’activité de l’équipe : sa vélocité, le travail qu’elle a accompli pendant le Sprint, les goulots d’étranglement qu’elle peut rencontrer et bien plus encore !

Il vous suffit de les prendre en main : testez-les pour comprendre ce qu’ils peuvent apporter et soyez attentifs dans la saisie des informations nécessaires à ces rapports.

Pour aller plus loin : mieux utiliser les termes agiles dans Jira Software

Ces rapports Jira s’appuient sur des notions de base de la méthode Agile :

  • Backlog
  • User Story
  • Epic
  • Version
  • Sprint

Il est primordial de comprendre et d’appréhender ces termes agiles, sans quoi les rapports Jira n’auront pas de sens.

Devenez familiers avec ces notions, passez de la théorie à la pratique dans Jira. Inscrivez-vous au Webinaire « Story, Epic, Sprint, Version: comment bien utiliser ces termes agiles dans JIRA software ? » le 15 Décembre 2022 (Replay disponible pour les inscrits) !

Les auteurs

Olga Campeis
Thomas Serre

Pour contacter les consultants SmartView par e-mail, utiliser l’adresse : prenom.nom@smartview.fr

Vous pouvez également les contacter via Linkedin