Article de blog

Organiser Jira

Utilisé au quotidien par des myriades d’équipes dans le monde, Jira a pourtant mauvaise réputation : mal configuré, Jira peut devenir un frein. Ou un allié s’il est configuré correctement dès le début.

Parmi toutes les plateformes de gestion de tickets déployées en entreprises, la plus utilisée est sans conteste Jira.

Jira est une plateforme collaborative destinée aux organisations et équipes qui ont adopté un cadre de travail agile (Scrum, Kanban, etc.). Les utilisateurs y manipulent des tickets (Epics, User Stories, etc.) regroupés au sein d’espaces de travail nommés “projets”.

Beaucoup d’organisations investissent dans Scrum mais délaissent Jira, bien que la plateforme soit utilisé quotidiennement par leurs équipes. Mal configuré, les utilisateurs s’y perdent : trop lent, illisible, pas adapté.

Il y a des raisons à ce déficit d’investissement : pas le temps, pas les compétences, etc. Jira a pourtant un véritable impact sur la performance des équipes.

C’est pourquoi je vous propose dans cet article une structure Jira qui facilite le quotidien des équipes et constitue une base solide pour étoffer votre plateforme par la suite.

Des besoins simples

Quel que soit le rôle de l’utilisateur Jira, la lisibilité est essentielle.

Un Product Owner doit pouvoir :

  • Naviguer facilement entre ses différents produits

  • Retrouver facilement les tickets en cours d’affinage (son quotidien)

Un Développeur doit pouvoir :

  • Avoir un espace de travail unique facilement accessible qui reflète la réalité des Sprints de l’équipe

  • Ne pas être pollué par des tickets qui ne le concernent pas (pas affinés, pas les siens, etc.)

Scrum.org

Les erreurs fréquentes

Les structures à éviter sont celles qui “mélangent trop” ou qui “séparent trop”.

Voici 3 exemples de configuration à éviter.

Le fourre-tout

Dans cette configuration, tout le monde partage un seul et même projet Jira. Deux cas de figure sont possibles :

  • Le projet Jira représente un projet de l’entreprise : toutes les équipes utilisent le même projet Jira

  • Le projet Jira héberge tous les Produits ou Projets d’une même équipe

C’est la configuration la plus facile à mettre en œuvre, mais c’est aussi la moins efficace en termes d’utilisation.

Parmi les inconvénients majeurs :

  • Tous les sujets sont mélangés (produits, projets, amélioration continue). Pour s’y retrouver, il faut ruser avec des champs personnalisés, des étiquettes, des filtres, etc.

  • Si plusieurs équipes utilisent le même projet, celui-ci va héberger plusieurs Sprints simultanés : retrouver son Sprint est fastidieux.

  • Compte tenu du nombre de tickets, les performances sont dégradées : le projet est long à charger, les recherches lentes, etc.

  • Le fin de vie d’un Produit se traduit par le déplacement des tickets correspondants (vers quoi ?)

 

Un espace de travail morcelé

Dans cette configuration, chaque équipe dispose d’un projet Jira pour chacun des Produits de son portefeuille (3 Produits, 3 projets Jira) et autant de Sprint Backlogs.

Parmi les inconvénients majeurs :

  • Les Sprints en parallèle (simultanés) n’aident pas l’équipe à gérer ses priorités ni à avoir une bonne visibilité sur le contenu de son véritable Sprint

  • L’utilisation quotidienne est fastidieuse car l’équipe doit basculer de projet en projet fréquemment

  • L’équipe ne sait pas où déposer ses actions d’amélioration continue

  • L’équipe ne bénéficie pas des rapports fournis nativement par Jira (ex. : Burn down chart)

  • Câbler un planning sur l’espace de travail de l’équipe devient impossible du fait des Sprints simultanés

L’usine à gaz

Dans cette configuration, chaque groupe de spécialistes (Dev, QA, Sys Admin, etc.) dispose de son propre projet Jira. Cette structure Jira est calquée sur un flux de travail très “saucissonné” (prévoir, faire, tester, livrer) et peu fluide.

Parmi les inconvénients majeurs :

  • La vision du Produit ou du Projet est morcelée (exécution sans vision utilisateur)
  • Un Workflow complexe est mis en place pour faire circuler les tickets d’un projet Jira à un autre (“prêt à tester”, “prêt à déployer”, etc.). Ou pire : les tickets sont déplacés d’un projet Jira à un autre !
  • Où est le “done” ?
  • Le Time To Market pâtit de ces passages de relais entre les différentes équipes

 

Une structure en entonnoir

Il est rare qu’un Product Owner et qu’une équipe n’interviennent que sur un seul produit. Le plus souvent, leur portefeuille est composé de plusieurs produits.

C’est pourquoi je vous propose une structure “en entonnoir” :

  • N projets Jira pour constituer le portefeuille Produit (1 projet Jira par Produit) : les Product Backlogs

  • 1 projet Jira pour l’équipe de Développeurs : le Sprint Backlog

Le portefeuille des produits

Prenons l’exemple d’un Product Owner qui pilote un portefeuille de 3 Produits : il disposera de 3 projets Jira, chacun hébergeant un Product Backlog.

Parmi les avantages :

  • Gain de lisibilité avec une organisation Jira cohérente avec la réalité des Produits
  • Possibilité d’associer un espace Confluence propre au Produit si une documentation est nécessaire
  • Possibilité d’associer une bibliothèque de cas de test (souvent nombreux) pour chaque Produit
  • Possibilité d’héberger les versions de chaque Produit
  • Un projet Jira est facile à archiver quand le produit correspondant est décommissionné

 

L’espace de travail de l’équipe

Toute l’équipe de Développement disposera d’un espace de travail unique qui lui est propre (Sprint Backlog).

Cet espace de travail est destiné à :

  • Afficher les tickets provenant des différents Product Backlogs sélectionnés par l’équipe de Développement pour être embarqués dans un Sprint

  • Héberger les tickets créés directement dans le Sprint Backlog (ex. : actions d’amélioration continue)

Parmi les avantages :

  • Un espace de travail plus lisible au quotidien

  • Possibilité de personnaliser le Workflow propre à l’équipe si nécessaire dans leurs espace de travail

  • Possibilité de créer des tickets pour suivre ses actions d’amélioration continue

  • Gain de performance réduisant le volume de tickets à afficher

  • Possibilité d’utiliser les rapports Jira dans le Sprint Backlog (vélocité, Burn down chart, etc.)

Les bons tickets au bon moment

Maintenant , voyons comment faire circuler l’information entre les Product Backlogs et le Sprint Backlog.

Pour que le Product Owner retrouve facilement les tickets en cours d’affinage et que l’équipe ne soit pas polluée par des tickets non prêts, le Workflow doit être adapté :

  • Ajouter 2 états au Workflow standard : Affinage (la Story est en cours d’affinage) et Prêt (la Story est prête à être embarquée dans un Sprint)

  • Adapter le Sprint Backlog pour n’afficher que les tickets en état Prêt, En cours et Terminé

 

Parmi les avantages :

  • En adaptant les Product Backlogs, on retrouvera facilement les US en cours d’affinage, tout en continuant à visualiser l’avancement des tickets en cours de Sprint (en cours, terminé)

  • En adaptant le Sprint Backlog, on disposera d’un espace de travail plus lisible qui reflète le résultat des Sprint Plannings.

 

L’utilisation

Après cette rapide mise en place, voici comment l’information circule :

  • Seules les User Stories affinées sont « déversées » dans l’espace de travail des Développeurs
  • En courts de Sprint, les changements d’état sont reflétés de part et d’autre

 

Aller plus loin : une structure extensible

La structure que je vous propose nécessite de maîtriser quelques bonnes pratiques d’administration Jira mais rien de compliqué ni de très coûteux (modèles de projets, versioning, etc.). Au contraire, sa simplicité facilitera son administration malgré le nombre de projets Jira.

Outre les avantages cités plus haut, c’est aussi une bonne base pour aller plus loin :

  • Déverser les Post-Its de vos Story Maps Miro dans vos Product Backlogs

  • Associer un espace Confluence pour documenter chaque Produit

  • Créer une bibliothèque de cas de test pour chaque Produit qui soit lisible (souvent de nombreux cas)

  • Mesurer la qualité du Produit en la couplant à votre ITSM : grâce à un Web Hook, un ticket d’incident créé dans votre ITSM déclenche la création d’un ticket d’incident dans le Product Backlog concerné.

  • Suivre les déploiements de vos Produits en couplant les Product Backlogs avec votre CI/CD

  • Mesurer l’investissement de l’effort par Produit : travaille-t-on sur les Produits zombis ou sur l’avenir ?

Ce qu’il faut retenir

Investir sur les facteurs de succès des projets, c’est aussi fournir à vos équipes des outils adaptés à leur activité quotidienne : une organisation Jira simple, sans surcoût et qui représente la réalité des portefeuilles et des flux de travail des équipes. Facilite à intégrer à votre système d’information, la structure proposée fournit une base durable pour des projets simples ou à l’échelle.