Avec plus de 500 000 projets Agile dans JIRA (pour les seuls clients Cloud, rendez-vous compte !), nous avons réalisé que nous disposions de volumes considérables de données pour nous aider à faire la lumière sur le fonctionnement des équipes Agile. Nous avons alors fait le pari qu’avec un peu de data mining anonymisé, nous pouvions trouver des équipes qui maintenaient leur rythme de livraison, sprint après sprint.

Les équipes qui livrent rapidement et régulièrement créent généralement près de 30 tickets par sprint 

Durant nos recherches, un constat nous a frappés : les équipes qui livrent rapidement et souvent (appelons-les « équipes orientées livraison ») créent généralement près de 30 tickets par sprint. Nous parlons ici d’équipes Agile composées de cinq à sept personnes. Trente tickets… ce chiffre peut sembler énorme, mais ce n’est pas tout. Il nous indique que les équipes orientées livraison subdivisent le travail en plusieurs petites couches de fonctionnalités. La décomposition des fonctionnalités en éléments granulaires permet aux petites équipes de se protéger et d’intégrer à un sprint uniquement le travail qu’elles sont sûres de pouvoir terminer.

Pour trouver le nombre idéal de tickets par sprint, votre équipe doit reconnaître que la portée d’un problème est trop vaste. Ensuite, elle doit prendre des mesures et apporter des changements dans JIRA en conséquence. L’user story d’origine doit-elle devenir un epic ? Doit-elle être subdivisée en plus petits blocs ou tâches ? Quelle est la place des sous-tâches ?

Pour répondre à ces questions, voyons comment subdiviser correctement les tickets tout en maintenant leur lien dans JIRA.

Comprendre les versions, les epics et les user stories

De récents articles de blog sur Portfolio pour JIRA ont bien présenté comment Portfolio pour JIRA organise le travail (En Anglais). De même, JIRA inclut une hiérarchie qui permet d’organiser le travail : les versions représentent la livraison à venir, les epics désignent une fonctionnalité ou une initiative unique, les tickets (user stories et tâches) représentent les éléments d’une fonctionnalité et les sous-tâches désignent des blocs de travail encore plus petits qui comprennent la story ou la tâche parente.

La portée de chaque élément est déduite de cette hiérarchie. Mais, votre équipe peut avoir dans son backlog une user story qui ressemble davantage à une fonctionnalité complète ou dont l’estimation est deux voire trois fois plus élevée que celle d’autres tickets. Dans les deux cas, la portée du ticket doit être réévaluée.

Si la description d’un ticket ressemble davantage à une fonctionnalité ou si la charge de travail menace de vous dépasser, le ticket doit être transformé en un epic, lequel sera ensuite relié aux user stories et aux tâches relatives à ses composants (plus d’infos dans la suite de l’article). Pour réaliser cette transformation dans JIRA, procédez comme suit :

  1. Créez le ticket et sélectionnez la liste déroulante More (Plus) en haut de l’écran.
  2. Cliquez sur Move (Déplacer) pour accéder à la page Select Project and Issue Type (Sélectionner un projet et un type de ticket).
  3. Recherchez l’élément Current Issue Type (Type de ticket actuel) et remplacez la valeur par Epic.
  4. Appuyez sur Next (Suivant). Vous serez alors invité à attribuer un nom à l’epic et à remplir les autres champs (le champ de nom est le seul obligatoire).
  5. Appuyez sur Next (Suivant) lorsque tous les champs sont à jour. Vous serez alors renvoyé vers la page de confirmation.
  6. Vérifiez les informations et appuyez sur Move (Déplacer). Et voilà. Vous avez maintenant un epic.

Conseil d’expert : Vous connaissez les raccourcis clavier JIRA ? Vous pouvez alors appuyer sur « e » pour accéder au mode Édition rapide (Quick Edit) et modifier le type de ticket si votre administrateur JIRA vous y a autorisé dans la configuration des champs.

Il est maintenant temps de créer les tickets des user stories qui composent votre fonctionnalité et de les associer à votre nouvel epic. La création de tickets dans JIRA est bien documentée (En Anglais), mais vous ne connaissez peut-être pas encore toutes les astuces :

  1. Si vous créez un nouveau ticket à l’aide du bouton Create (Créer) situé en haut de l’écran, votre ticket sera automatiquement ajouté en haut de votre backlog.
  2. Si vous avez sélectionné un ticket dans le backlog, lorsque vous appuyez sur le bouton Create (Créer), votre nouveau ticket apparaît juste à côté du ticket sélectionné.
  3. Si vous attribuez le ticket à un sprint lors de sa création, le ticket sera ajouté au bas de ce sprint.
  4. Si vous vous trouvez dans le backlog et que vous cliquez sur le lien Create Issue (Créer un ticket) en-dessous d’un sprint, JIRA ajoutera des attributs pour refléter le tableau ainsi que tout filtre appliqué. Par exemple, si votre tableau n’affiche actuellement que les tickets associés à l’epic « Client mobile », les tickets ainsi créés seront automatiquement associés à l’epic « Client mobile ».

Image1

Et d’ailleurs, l’association de tickets avec des epics est on ne peut plus simple.

  1. Accédez à votre backlog et cliquez sur le lien Epicssur la gauche afin d’afficher tous vos epics.
  2. Sélectionnez un ticket dans le backlog et faites-le glisser vers la liste des epics.
  3. Déposez le ticket sur l’epic auquel vous souhaitez l’associer. Et voilà. Votre ticket affiche maintenant un losange coloré et le nom de l’epic.

Vous savez maintenant comment modifier le type de ticket pour refléter sa portée, le cas échéant. Inversement, si votre user story ne représente pas une fonctionnalité complète, mais nécessite plus de travail que ce qu’une personne seule pourrait effectuer dans un seul sprint, vous devez la subdiviser en plusieurs tickets. Reconnaître les cas dans lesquels cette opération est nécessaire revient à comprendre les estimations de votre équipe.

L’équipe marketing JIRA utilise par exemple des story points pour ses estimations. Lorsqu’une user story est estimée à 20 points ou plus, nous considérons cela comme un signal d’alerte : l’estimation du ticket est trop importante pour être réalisée dans nos sprints de deux semaines. Ce signal d’alerte ne s’applique qu’à notre équipe et dépend du calibrage de nos story points. Le vôtre peut varier. Pour le fun, imaginons que votre équipe de développement soit calibrée de la même façon et réalise des sprints de deux semaines. Vingt story points indiqueraient qu’une user story contient trop d’inconnues ou est trop ambitieuse. C’est alors à votre équipe – composée de responsables produit, de développeurs, de testeurs et de scrum masters – de la subdiviser en tickets plus petits.

Image2

Vous souhaitez en savoir plus sur les estimations ?
Une estimation peut s’avérer difficile, car certaines équipes utilisent comme unité de calibrage les heures alors que d’autres utilisent les story points. Les story points représentent l’effort relatif nécessaire. Ils sont exprimés à un format similaire à la suite de Fibonacci : 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Même si ces nombres semblent abstraits, les équipes s’habituent plutôt rapidement à cette forme d’estimation : Lisez notre article Collaboration, Abstraction, and other Secrets of Agile Estimation (En Anglais) (Collaboration, abstraction et autres secrets de l’estimation Agile) pour en savoir plus.

Clonage, association et sous-tâches

Si vous décidez de subdiviser une user story en deux tickets, votre meilleure solution reste la copie (ou le clonage pour reprendre la terminologie JIRA). Avec le clonage, le nouveau ticket contient toutes les informations du ticket source : résumé, type de ticket, epic, version, date d’échéance, responsable, etc. Il va de soi que vous devrez mettre à jour les descriptions (pour faire simple, les subdiviser en deux parties) pour refléter la portée à donner à chaque ticket. Vous devrez peut-être aussi modifier le responsable et la version de fix indiqués dans le ticket cloné selon la situation.

Si vous n’avez encore jamais cloné de ticket, voici comment procéder :

  1. Créez le ticket et sélectionnez la liste déroulante More (Plus) dans la section Actions.
  2. Cliquez sur Clone (Cloner). Vous accéderez alors à une boîte de dialogue vous invitant à saisir le résumé du ticket cloné.
  3. Appuyez sur Edit (Modifier) et apportez vos changements comme vous le feriez avec n’importe quel autre ticket.

Conseil d’expert :
JIRA est plein de ressources. Appuyez sur le raccourci clavier « . » (point) pour accéder à la boîte de dialogue Operations (Opérations). Une fois cette dernière ouverte, vous pouvez entrer une action (par exemple, Clone (Cloner) pour ouvrir la boîte de dialogue sans devoir utiliser la barre de navigation en haut de votre ticket. N’oubliez pas ce raccourci, il peut vous servir pour toutes vos actions : afficher la progression, joindre une capture d’écran, arrêter le suivi… et j’en passe.

Image3
Un autre avantage du clonage : le nouveau ticket s’affichera dans la section Issue Links (Tickets associés) du ticket d’origine et sera accompagné du type de lien « cloné comme » et d’une référence au nouveau ticket. De même, la section Issue Links (Tickets associés) du nouveau ticket comprendra une référence au ticket d’origine accompagnée du type de lien « cloné à partir de ».

Ces liens pratiques vous permettent d’établir des relations entre les tickets. JIRA offre quelques liens de base, comme « cloné comme/à partir de » et « bloque/bloqué par », mais vous pouvez contacter votre administrateur JIRA pour ajouter des types de lien personnalisés. Vos possibilités sont quasi illimitées ! Chez Atlassian, nous avons notamment ajouté le type de lien personnalisé « entraîne/entraîné par » pour refléter les situations dans lesquelles un changement apporté au code entraîne un nouveau bug.

Si deux tickets sont associés, leur relation s’affichera dans la section Issue Links (Tickets associés). Vous verrez également la priorité et le statut des tickets associés. Fini les va-et-vient entre les tickets ou les recherches pour vérifier qu’un ticket est bel et bien clôturé.

Image4

Que vous tentiez ou non de séparer des tickets et quelle que soit l’organisation habituelle de vos tickets pour un projet, l’association est simple. Voici comment associer des tickets :

  1. Créez le ticket et sélectionnez la liste déroulante More (Plus) dans la section Actions.
  2. Cliquez sur Link (Lien) ou commencez à taper pour accéder à la boîte de dialogue vous invitant à entrer la relation et le ticket avec lequel vous établissez la relation.
  3. Appuyez sur Link (Lien). Le lien s’affichera dans la section Issue Links (Tickets associés) du ticket.

Si vous souhaitez gagner du temps, utilisez la boîte de dialogue Operations (Opérations) déjà évoquée.

Qu’en est-il des sous-tâches ? Certaines équipes les utilisent pour répertorier les étapes distinctes impliquées dans la gestion d’un ticket. D’autres en raffolent lorsque plusieurs personnes doivent contribuer à la gestion d’un ticket. Au lieu de changer de responsable, il est possible d’affecter cinq sous-tâches à cinq personnes différentes. Comme pour l’association, votre administrateur doit activer les sous-tâches (En Anglais). Une fois cette activation terminée, accédez simplement au menu More (Plus) et sélectionnez Create Sub-Task (Créer une sous-tâche) pour créer une sous-tâche. Ce même menu vous permet de convertir un ticket existant en sous-tâche.

Les sous-tâches sont généralement ajoutées au cours de la préparation du backlog ou de la planification du sprint, des situations dans lesquelles il pourrait être utile de décomposer une user story. Cette approche simplifie l’estimation, puisque la fin est plus facilement perceptible lorsque le ticket est plus restreint. Vos estimations sont plus faciles à réaliser et sont généralement plus précises.

Comme tous les autres éléments de JIRA, les sous-tâches sont personnalisables. Par exemple, si vous le souhaitez, vous pouvez faire en sorte que les user stories ne passent pas au statut de workflow suivant après la clôture de toutes les sous-tâches. C’est simplement un outil supplémentaire qui permet à votre équipe de planifier plus intelligemment et de trouver le bon rythme de livraison.

Conseil d’expert :
Toutes les sous-tâches doivent être terminées pour clôturer un sprint. Lorsqu’une sous-tâche est toujours ouverte, mais que le ticket parent peut être fermé (par exemple, si la sous-tâche de mise à jour des documents est toujours ouverte, mais que la fonctionnalité est opérationnelle), vous pouvez transformer la sous-tâche en ticket et clôturer votre sprint. Mais n’oubliez pas que cette action risque d’apparaître dans les rapports de votre sprint lorsque la portée s’élargit.

Habitudes des équipes orientées livraison

Même si, sur plus de 500 000 projets Agile dans JIRA, le nombre idéal de tickets par sprint avoisine les 30 pour les équipes orientées livraison, l’essentiel est que la portée des tickets permette de les clôturer au cours du sprint. Si vous détectez un ticket trop ambitieux, que le convertissez en un epic ou le décomposez en tickets plus petits, vous garantissez votre réussite et vous aiderez votre équipe à rester orientée livraison, sprint après sprint.

À noter que nous avons également remarqué d’autres modèles et tendances au sein des équipes orientées livraison. Pour en savoir plus, consultez notre dernière infographie : l’équipe orientée livraison.

Consultez notre infographie sur l’équipe orientée livraison