Le coût caché des tickets Jira vagues
Un ticket Jira vague paraît rarement problématique au premier abord. Le vrai souci arrive plus tard, quand différentes personnes remplissent les vides avec des hypothèses différentes et que plusieurs jours de travail concentré partent dans la mauvaise direction.
Pourquoi les tickets vagues survivent
Une ingénieure back-end prend un ticket le lundi matin. Le titre paraît précis : « Ajouter des notifications utilisateur pour les mises à jour de commande ». La description contient deux phrases et un lien vers un fil Slack vieux de trois semaines. Cela semble suffisamment clair. Elle passe trois jours à construire un pipeline d’e-mails déclenché à chaque changement d’état d’une commande.
Le jeudi, pendant la revue de PR, la PM arrive et dit : « Ce n’est pas ce que je voulais dire. On avait seulement besoin de notifications dans l’application pour les événements d’expédition, et les utilisateurs devaient pouvoir les désactiver. » Personne n’avait tort. Personne n’avait bâclé le travail. Le ticket n’avait simplement jamais fait remonter les décisions qu’il cachait.
Personne ne rédige volontairement un ticket vague. On l’écrit en deux minutes entre deux réunions, avec l’intention sincère d’y revenir pour ajouter des détails. On n’y revient jamais. La personne qui le rédige garde tout le contexte en tête. Elle sait quels événements comptent, quels canaux elle imagine, quels utilisateurs sont concernés.
Rien de tout cela ne se retrouve sur la page, parce que cela paraît évident. Pour les autres, ça ne l’est pas.
Jira aggrave le problème précisément parce qu’il le rend facile. Aucun champ obligatoire ne demande ce qui est explicitement hors périmètre. Aucun garde-fou ne rejette une description de moins de vingt mots. On peut écrire trois mots dans le résumé, laisser la description vide et cliquer sur Créer. Jira ne proteste pas. C’est à la fois une qualité et un piège. On se retrouve donc avec un backlog plein de tickets qui ont l’air complets au premier coup d’œil et qui ne révèlent leur flou qu’au moment où quelqu’un commence à développer.
Ce qu’un plan vraiment prêt à construire contient
La plupart des tickets répondent à une seule question : qu’est-ce qu’on veut ? Un plan prêt à construire en répond à six.
| Partie | Ce à quoi elle répond |
|---|---|
| Périmètre | Ce qui est inclus et ce qui est explicitement exclu |
| Contraintes | Ce qui ne peut pas changer ni casser |
| Étapes | Ce qu’il faut faire, et dans quel ordre |
| Cas limites | Ce qui se passe quand le chemin évident ne fonctionne plus |
| Dépendances | Ce qui doit exister en amont |
| Définition du terminé | Comment tout le monde saura que le travail est réellement fini |
Ce n’est pas une grille à appliquer à chaque minuscule correction du backlog. Mais tout ce qui part dans un sprint, tout ce qui risque de consommer plus que quelques heures du temps de quelqu’un, a besoin de ces réponses avant le démarrage. Le périmètre est la partie que les équipes sautent le plus souvent. Dire explicitement ce qui n’est pas inclus paraît superflu quand on est focalisé sur ce qui l’est. Pourtant, c’est là qu’une part étonnante du retravail commence.
Les contraintes sont les exigences silencieuses :
- Ne pas casser le flux actuel d’e-mails de commande.
- Rester dans le service de notification existant.
- Pas de nouvelle infrastructure sur ce sprint.
Ces détails sont rarement écrits parce que la personne qui rédige suppose que tout le monde les connaît déjà. Ce n’est pas le cas. Et la définition du terminé est la frontière entre « je pense que c’est fini » et « nous sommes d’accord pour dire que c’est fini ». Une bonne définition du terminé est observable et vérifiable.
Les questions viennent avant la structure
Toutes les instances Jira finissent par passer par le même cycle. Quelqu’un ajoute un modèle de description avec des sections comme Résumé, Critères d’acceptation, Notes techniques et Hors périmètre. Pendant quelques semaines, tout le monde le remplit. Puis le même flou qui vivait auparavant dans une description vide se met simplement à se répartir dans davantage de cases étiquetées. La structure s’est améliorée. Pas la réflexion.
Les modèles ne résolvent pas le problème parce que le problème n’est pas structurel. Il est cognitif. La personne qui rédige ne sait pas ce qui lui manque. Une section vide intitulée Cas limites n’aide pas quelqu’un qui n’a pas encore pensé aux cas limites. Les questions, si. Des questions concrètes, précises, qui obligent à trancher.
Cinq questions font particulièrement bien remonter les décisions cachées :
- Qu’est-ce qui change dans le comportement du système ?
- Qui est l’acteur principal, et qu’essaie-t-il d’obtenir ?
- Y a-t-il un cas où cela ne doit pas se produire ?
- Qu’est-ce qui casse si on ne livre pas cela ?
- Cela concerne-t-il les utilisateurs existants, les nouveaux utilisateurs, ou les deux ?
Ces questions fonctionnent parce qu’elles sont assez précises pour recevoir une réponse, mais assez larges pour s’appliquer à presque n’importe quel ticket de fonctionnalité. Le fait d’y répondre, c’est déjà la planification. Le modèle n’est que l’endroit où l’on dépose les réponses.
Exemple complet
Voilà à quoi cela ressemble en pratique. Le ticket d’origine est minuscule : « Ajouter des notifications utilisateur pour les mises à jour de commande ». La description se contente d’indiquer que les utilisateurs doivent être notifiés quand le statut d’une commande change, avec une note invitant à voir avec le design pour le traitement visuel. C’est suffisant pour le faire entrer dans un sprint, mais pas du tout suffisant pour développer sereinement.
Un court tour de clarification change complètement la donne :
| Question de clarification | Réponse |
|---|---|
| Quels changements de statut comptent ? | Seulement expédié et livré |
| Quels canaux ? | Dans l’application uniquement pour ce sprint |
| L’utilisateur peut-il les désactiver ? | Oui, avec activation par défaut |
| Et pour les utilisateurs hors ligne ? | La notification est mise en attente jusqu’à la prochaine connexion |
| Cela s’applique-t-il aux commandes existantes ? | Non, seulement aux nouvelles |
| Que se passe-t-il en cas d’échec de livraison ? | Une nouvelle tentative, puis journalisation |
Quinze minutes plus tard, le ticket signifie une seule chose pour tout le monde. La version d’après contient un vrai périmètre, de vraies contraintes, des étapes ordonnées, de vrais cas limites et une définition du terminé qui peut être testée. C’est le même ticket. La clarté n’a plus rien à voir. La différence ne vient pas d’un meilleur modèle. Elle vient d’un petit effort conscient de clarification avant de se mettre au travail.
Où l’IA s’insère dans ce processus
L’IA n’écrit pas les tickets. Ce sont les personnes qui écrivent les tickets. En revanche, l’IA est utile à un moment très précis du processus : une fois l’intention formulée, avant que la structure ne soit figée. Un modèle de langage sait lire une description vague et demander : « Avez-vous pensé à ce qui se passe quand l’utilisateur est hors ligne ? » Il sait prendre des réponses dispersées dans un fil Slack et les organiser en périmètre, contraintes et étapes. Il sait remarquer qu’un plan mentionne une migration de base de données alors que la liste des dépendances ne prévoit pas la relecture par les bonnes personnes.
Ce que l’IA ne sait pas bien faire, c’est prendre les décisions produit à votre place. Elle peut demander s’il faut passer par e-mail, par notification push ou dans l’application. Elle ne peut pas décider laquelle de ces options est la bonne pour vos utilisateurs et pour votre sprint. Elle peut générer une définition du terminé crédible, mais seule une personne qui connaît le produit peut savoir si cette définition est réellement juste.
Le schéma est simple : les humains décident, l’IA structure. Les humains fixent le périmètre, l’IA repère les trous. C’est exactement ce schéma, clarifier, planifier, exécuter, sur lequel Just sur l’Atlassian Marketplace est construit dans Jira. Le même schéma fonctionne aussi manuellement. L’IA rend simplement la boucle plus rapide.
Trois choses à appliquer dès aujourd’hui
- Avant votre prochain sprint, prenez le ticket le plus vague de votre backlog et posez les cinq questions de cet article avant que quiconque n’écrive une ligne de code. Vous découvrirez presque à coup sûr au moins deux décisions que personne n’avait réalisé ne pas avoir encore prises.
- Notez les réponses comme périmètre, contraintes et définition du terminé vérifiable, non pas dans un document séparé, mais dans le ticket lui-même, là où la personne qui va l’implémenter les verra réellement.
- Considérez le modèle ci-dessus comme un point de départ, pas comme une norme rigide. Adaptez-le au langage de votre équipe, mais ne sautez pas les questions. Si vous voulez le cadre plus large pour comprendre pourquoi cette étape de clarification devient encore plus importante quand des tickets vagues sont donnés directement à une IA, le premier article de cette série détaille le problème d’alignement : Pourquoi la plupart des outils d’IA pour Jira aggravent le problème d’alignement au lieu de le résoudre.
