Planifier avec Jira

Si vous bénéficiez d’un abonnement Jira Premium, vous pouvez utiliser Advanced Roadmap, la brique de planification de Jira.

Nous allons voir comment concevoir et utiliser un planning pour l’activité d’une équipe.

Mise en place

Avant de planifier quoi que ce soit, il est nécessaire de paramétrer votre planning :

1. Le “câbler” sur votre activité (Backlogs)
2. Ajouter votre équipe et sa “capacité à faire”

Créer le planning

Nous allons créer le planning de l’équipe e-commerce. Si vous avez organisé Jira comme proposé dans un article précédent, rien de plus simple !

Pour cela, il suffit de le “câbler” sur :

• Les tickets de l’équipe
• Les Sprints de l’équipe

Les tickets des Backlogs de l’équipe apparaissent maintenant dans le planning.

Créer l’équipe

Maintenant que nous disposons de la matière (les tickets) dans notre planning, ajoutons le rythme !

Le rythme, c’est l’équipe : c’est elle qui sprinte et qui porte la réalité de l’avancement.

Advanced Roadmap utilise 2 informations essentielles relatives à l’équipe :

• La durée du Sprint
• La vélocité de l’équipe

☝️La vélocité est la vélocité actuelle. Elle n’est pas historisée. Elle peut être modifiée à tout moment. Il est possible de modifier la vélocité pour un Sprint en particulier (le Sprint doit exister dans Jira).

☝️Ajouter les membres de l’équipe est facultatif. Le nombre de membres ou l’absence de membres n’a aucune incidence sur le planning.

Construire le planning prévisionnel

Nous sommes maintenant prêts à démarrer la construction du planning prévisionnel.

Nous procèderons en 2 temps :

1. Elaborer notre meilleure proposition pour voir « où ça nous mène »
2. Créer les incréments pour packager les livrables

Elaborer sa meilleure proposition

Nous allons mettre en regard les Epics chiffrés et la vélocité de l’équipe. 

Pour cela, il suffit de : 

1. Associer l’équipe aux Epics
2. Placer les Epics sur le planning en prenant soin de ne pas surcharger l’équipe

☝️Une équipe surchargée pour un Sprint apparaîtra en rouge pour ce Sprint

☝️Seuls les tickets « non sprintables » sont à planifier de la sorte : les tickets embarqués dans un Sprint héritent des dates du Sprint.

Créer les incréments

Un macro planning est constitué des Epics que vous avez identifiés. Ils n’ont pas encore été décomposés en Stories mais sont déjà été estimés. Vous avez peut-être même déjà identifiés les incréments en atelier.

Commençons par créer les incréments (version ou livraison dans Jira) :

1. Créer une version à date de fin flexible
2. Associer les Epics à la version

Vous disposez maintenant d’un planning prévisionnel qui représente vos ambitions. Avec sa représentation graphique, il peut ête présenté à un auditoire.

Utiliser le planning opérationnel

Parfois, les choses prennent plus de temps que prévu et “dérivent”. Il est essentiel d’être prévenu au plus tôt pour prendre les décisions qui s’imposent : reporter la date d’atterrissage ou embarquer moins de fonctionnalités dans l’incrément.

Le but d’un planning est de confronter votre ambition avec la réalité :

1. Votre ambition, ce sont les Epics que vous avez planifiés avec des dates de début et de fin.
2. La réalité, c’est ce que vous n’avez pas planifié. Ce sont les Stories qui sont sprintées par l’équipe.

Caler les jalons

Vous avez élaboré un planning prévisionnel et il vous plait. Il convient donc de caler les jalons pour pouvoir détecter une éventuelle dérive : il suffit de passer les versions en date de fin fixe. A partir de là, la date de fin est représentée par une ligne dans le planning.

Connaître l’avancement

De ce côté, Jira ne propose que des choses très simples.

L’avancement peut être suivi à 2 niveaux (à l’Epic et à la version) et de 2 manières (au nombre de tickets ou aux Story Points).

L’avancement exprimé en nombre de tickets représente le nombre de tickets terminés rapporté au nombre total de tickets.

L’avancement en Story Points représente la somme des points des tickets terminés rapportée au nombre de points total de l’Epic :

Comme vous le voyez, les façons de mesurer l’avancement produisent des résultats très différents. Je n’évoquerai pas les jours homme, cette unité n’ayant jamais été un indicateur d’avancement mais plutôt de consommation de moyens.

Le suivi à l’Epic (ou tout autre niveau parent) est basé sur l’avancement des Stories (ou tout autre ticket enfant) :

L’avancement à la version ne propose que l’avancement au nombre de tickets :

Détecter une dérive

Le planning estimé est calé, le premier Epic a été décomposé en Stories chiffrées. L’équipe embarque des Stories à hauteur de sa vélocité en prenant garde à ne pas se surcharger.

Le Sprint 33 démarre. Et là, c’est le drame : ll’équipe ne parvient pas à terminer l’une des Stories. Elle sera donc reportée au Sprint 34.

Problème : pour ne pas être surchargée, l’équipe doit repousser une Story en Sprint 35.

C’est là que la dérive est signalée : le Sprint 35 se terminant après la date de fin souhaitée pour la version Lot 1 – Créer son compte, la version passe en rouge pour signaler que le délai ne sera pas tenu.

Ce qu’il faut retenir

Planifier son activité n’est pas une fin en soi. Pour une équipe, il s’agit de « prendre son destin en main », d’élaborer des propositions et d’être alerté en cas de dérive pour que des décisions soient prises (date, périmètre). Inutile de détailler une année entière !

Avec Jira Advanced Roadmaps, planifier est relativement simple.

Pour aller plus loin, vous pouvez consulter la documentation de l’éditeur.