Quelles sont les trois façons de gérer une liste dans Jira ?
Les cases à cocher natives de la description (et les éléments d’action) forment une liste ponctuelle sur le ticket. Les sous-tâches sont des tickets enfants avec leur propre responsable, leur estimation, leur date d’échéance et leur workflow. Checklist for Jira garde une liste structurée sur le ticket parent — modèles, progression, validateurs — sans créer de tickets supplémentaires. Le guide des checklists Jira détaille comment ajouter cette liste ; cette page est le guide de décision.
Aucune des trois n’est un pis-aller. Les trois étapes de vérification d’un rapporteur ont leur place dans la description. Une revue de design portée par une autre équipe mérite une sous-tâche. Definition of Done, une checklist de tests QA et un runbook de mise en production ont leur place sur le ticket parent, sous forme de checklists, pour que le seuil de qualité voyage avec la story.
Pourquoi choisir en connaissance de cause
Quand chaque ligne « on n’a pas oublié ? » devient une sous-tâche, le tableau se remplit de cartes qui n’auraient jamais dû être des tickets. Quand le seuil de qualité ne vit que dans Confluence, il est facile de le sauter. Une checklist sur le ticket est la voie médiane : les mêmes étapes chaque fois, une progression visible sur le ticket et dans JQL, et toujours un seul ticket parent pour cette part de travail.
Bien les combiner simplifie le processus. Le tri des demandes reste léger. La livraison garde un seuil de qualité partagé. Les véritables unités de travail conservent leur propre ticket enfant. Checklist for Jira est fait pour les listes que vous répétez ; Jira gère déjà le reste.
Quand utiliser chacune
Utilisez les cases à cocher de description pour une liste que vous ne réutiliserez jamais. Utilisez une checklist quand les mêmes étapes reviennent sur chaque story, bug ou changement — surtout si vous voulez des modèles, une barre de progression ou un verrou de workflow. Ouvrez une sous-tâche quand le travail constitue une unité autonome, avec son propre responsable, son estimation et son statut sur le tableau.
Mettez la checklist sur l’élément de travail, pas dans la description
Checklist for Jira apporte les modèles, l’automatisation, les validateurs de workflow et un agent Rovo. Gratuit pour les équipes jusqu’à 10 utilisateurs.
Côte à côte
| Besoin | Cases à cocher de description | Checklist for Jira | Sous-tâches |
|---|---|---|---|
| Responsabilité | Vit dans la description ; facile à manquer dans un champ long | Sur le ticket, avec mentions et statuts d’élément | Responsable propre à chaque ticket enfant |
| Workflow indépendant | Non | Statuts d’élément comme Open, In Progress, Blocked, Done | Workflow, statut et transitions complets du ticket |
| Estimations et dates d’échéance | Non | Dates et mentions sur les éléments, pas une estimation complète de ticket | Story points, temps et date d’échéance sur l’enfant |
| Suivi sur le tableau | Non | Progression sur le ticket, sur les tableaux et dans JQL | Chaque enfant apparaît comme sa propre carte |
| Progression légère | Lecture manuelle de la description | Barre de progression et compteur de complétion | Agrégation des tickets enfants |
| Modèles | Non | Modèles de projet et globaux, y compris Protected | Modèles de ticket uniquement |
| Plusieurs listes sur un même parent | Non | Oui — Done, QA et mise en production peuvent coexister | Oui, en tickets séparés |
| Validation | Non | Bloquer une transition jusqu’à ce qu’une liste (ou une liste nommée) soit complète | Conditions de workflow par ticket |
| Automatisation | Non | Ajout automatique à la création ou au changement de statut ; Jira Automation pour appliquer, terminer ou réinitialiser | Jira Automation sur les tickets |
| Charge de gestion | La plus faible — saisie dans la description | Un panneau sur le ticket parent, sans tickets supplémentaires | Un nouveau ticket pour chaque part de travail |
Quand les sous-tâches sont le bon outil
Créez une sous-tâche quand le travail constitue une unité autonome, pas un contrôle qualité. Une revue de design portée par une autre équipe, une tâche de migration de données avec sa propre estimation, une revue de sécurité avec un workflow séparé — tout cela mérite un ticket enfant. Les checklists ne remplacent pas ça. Elles remplacent la dizaine de lignes « on n’a pas oublié ? » qui n’auraient jamais dû devenir des tickets.
Quand une checklist sur le parent est le meilleur choix
Gardez Definition of Done et les critères d’acceptation sous forme de checklists sur la story pour que le seuil de qualité et le comportement promis restent visibles ensemble. Attachez une checklist de tests QA quand les testeurs prennent en charge une passe de vérification. Utilisez un modèle Protected quand le texte ne doit pas dériver. Appliquez-les et exigez-les avec le guide d’automatisation pour que le processus apparaisse sans cartes supplémentaires sur le tableau.
Exemples issus de la livraison, de la QA et de l’onboarding
- Livraison : gardez Definition of Done et les critères d’acceptation sous forme de checklists sur la story. Séparez une investigation de performance dans une sous-tâche avec sa propre personne responsable.
- QA : exécutez la checklist de tests QA sur le ticket parent. Ouvrez une sous-tâche uniquement quand un échec nécessite un responsable de la correction et un workflow distincts.
- Onboarding : une checklist Protected sur le ticket d’embauche suffit pour les comptes, le matériel et les présentations. Une sous-tâche est adaptée quand l’IT doit suivre une commande d’ordinateur portable comme une part de travail à part entière.
À combiner avec le reste du dispositif de livraison
Quand vous êtes prêt à réutiliser une liste, partez du modèles de checklist et reliez-la au guide d’automatisation. Le guide des checklists Jira couvre les options natives et la façon d’ajouter une checklist. Réservez les sous-tâches au travail qui mérite un ticket ; réservez les checklists au processus qui doit rester sur le ticket parent.
FAQ
Faut-il bannir les sous-tâches ?
Réservez les sous-tâches au travail qui est vraiment un ticket enfant — avec son propre responsable, son estimation et son workflow. Utilisez une checklist pour le seuil de qualité qui doit rester sur le ticket parent.
Les cases à cocher de description sont-elles un mauvais choix ?
Elles restent la solution la plus rapide pour une liste que vous ne réutiliserez jamais. Passez à un modèle dès que les mêmes étapes reviennent sur chaque story.
Une story peut-elle avoir des checklists et des sous-tâches ?
Oui — c’est souvent la configuration la plus saine. Definition of Done et QA restent sur le ticket parent. Une revue de design ou une tâche de migration se place à côté, en sous-tâche.
Quand une ligne de checklist doit-elle devenir une sous-tâche ?
Quand cette ligne nécessite son propre responsable, une estimation et un statut que le tableau doit afficher comme une carte distincte. En attendant, gardez-la sur le ticket parent pour que le seuil de qualité reste une seule barre de progression.
Mettez la checklist sur l’élément de travail, pas dans la description
Checklist for Jira apporte les modèles, l’automatisation, les validateurs de workflow et un agent Rovo. Gratuit pour les équipes jusqu’à 10 utilisateurs.