Mieux écrire ses tickets : distinguer bug et évolution pour clarifier son backlog
- Publié par Romain
- le
- Thématique : Organisation du travail
Quand on pilote un backlog et qu’on a un profil ou un passé technique, il est facile de créer des tickets techniques. Sur le moment ça semble tout à fait adapté mais ensuite l’équipe ne sait plus toujours quoi comprendre, quoi faire ou comment vérifier que le sujet est vraiment traité puisqu’elle va simplement exécuter une solution un problème qu’elle ne connaît pas. C’est un sujet que nous voyons régulièrement dans les équipes produits : des tickets à consonance technique souvent très clair pour leurs auteurs mais beaucoup moins exploitable qu’il n’y paraît. L’enjeu dans cet article, c’est de revenir sur une pratique courante qu’il est essentiel d’améliorer pour avoir des équipes plus alignées sur une vision produit.
Le problème, c’est qu’un ticket flou finit souvent par générer des allers-retours, des malentendus et des développements qui partent trop vite sur une solution. L’intérêt de mieux écrire c’est de mieux prioriser, développer et mieux tester.
Pourquoi tant de tickets "vieillissent" mal
Dans beaucoup d’équipes, on crée un ticket dès qu’on repère quelque chose :
- un comportement étrange à l’écran,
- une idée d’amélioration,
- une évolution qui semble évidente,
- un détail repéré pendant les tests.
Sur le moment, la personne qui crée le ticket a encore le sujet en tête, elle sait ce qu’elle veut dire, elle se souvient du contexte. Mais quelques jours plus tard, des informations se perdent en route.
- Le ticket est repris par quelqu’un d’autre.
- Ou bien il ressort après plusieurs semaines en inbox.
- Ou il réapparaît au moment d’arbitrer la roadmap.
Et là, on découvre que le ticket est trop léger. On ne sait plus exactement :
- Quel est le problème,
- Comment le reproduire,
- Ce qui est attendu,
- Et comment vérifier que c’est bon.
C’est souvent là que le backlog commence à perdre en qualité.
Un bon ticket ne commence pas par la solution
Beaucoup de tickets sont écrits avec un réflexe technique ce qui est logique. Quand on connaît bien son produit, son architecture et ses contraintes, on pense vite en termes de solution, on écrit par exemple :
- Retirer un scroll,
- Enregistrer une donnée en base,
- Modifier une requête,
- Rafraîchir un écran,
- Revoir un formulaire.
Le souci, c’est que ce vocabulaire parle surtout du comment. Or un ticket utile, surtout côté produit, a intérêt à commencer par le quoi. Un bon ticket ne décrit pas d’abord la mécanique. Il décrit le besoin ou le résultat attendu. En réalité, ça change beaucoup de choses parce qu’à partir du moment où le ticket est mieux posé, les discussions d’équipe deviennent plus claires elles aussi.
Pourquoi “retirer le scroll” n’est pas la meilleure formulation ?
Écrire : “retirer le scroll vertical”, c’est déjà proposer une solution mais peut-être que la bonne solution ne sera pas de retirer un scroll. Peut-être qu’il faudra revoir la taille d’un composant. Ou la disposition des éléments. Ou le comportement de l’écran. Le ticket n’a pas besoin de trancher cela trop tôt. Ce qu’il doit exprimer, c’est le résultat attendu :
- l’écran doit rester lisible,
- l’information doit être visible,
- le parcours doit rester fluide,
- le comportement doit être cohérent pour l’utilisateur.
Cette manière d’écrire évite de transformer trop vite un besoin en prescription technique.
Première étape : distinguer un bug d’une évolution
Ça peut sembler basique, mais c’est un bon point de départ. On n’écrit pas de la même manière un bug et une évolution.
- Un bug part d’un écart constaté. Quelque chose ne se comporte pas comme prévu.
- Une évolution part d’un besoin. On veut rendre possible une nouvelle action, améliorer un parcours, ajouter une information, faire gagner du temps à l’utilisateur, clarifier une interface ou rendre une fonctionnalité plus utile.
Le ticket doit alors expliciter ce besoin, sans basculer trop vite dans la solution. Cette distinction évite déjà beaucoup de confusion parce qu’un bug demande d’abord de reproduire et corriger. Là où une évolution demande d’abord de comprendre et cadrer.
Structure simple pour écrire un ticket de bug
Quand il s’agit d’un bug, il n’y a pas besoin d’en faire trop. En revanche, il y a quelques informations très utiles à retrouver presque à chaque fois.
1. Constat
Qu’observe-t-on réellement ?
2. Procédure
Quelles étapes permettent de reproduire le problème ?
3. Situation désirée
Quel état final souhaite-t-on obtenir ?
4. Procédure de test
Comment vérifiera-t-on que le bug est bien corrigé ?
5. Pièces utiles
Capture, vidéo, logs, contexte, environnement de test si besoin.
Cette structure a l’avantage de ne pas reposer uniquement sur la mémoire de la personne qui a créé le ticket.
Exemple de ticket utile
Un ticket est créé avec un titre du type : Scroll vertical sur l’écran atelier
Et dans la description : “Quand on ajoute un bloc PDF, il y a un scroll vertical.” Pour la personne qui vient de le constater c’est clair mais pour le reste de l’équipe, c’est encore léger. Voici une version plus exploitable.
Titre
Un scroll vertical apparaît sur l’écran atelier lors de l’ajout d’un bloc PDF
Constat
Lorsqu’un bloc PDF est affiché sur l’écran atelier, un scroll vertical apparaît alors que l’ensemble des éléments devrait rester visible sans défilement vertical.
Procédure
- Ouvrir l’écran atelier
- Ajouter un bloc PDF
- Revenir à l’affichage principal
- Constater l’apparition du scroll vertical
Situation désirée
L’écran reste lisible sans scroll vertical parasite, avec tous les éléments visibles dans le cadre prévu.
Procédure de test
Rejouer les étapes ci-dessus après correction et vérifier que le scroll vertical n’apparaît plus.
Pour une évolution, revenir à un langage produit
Sur les évolutions, le piège est similaire. On voit souvent des tickets rédigés de façon très orientée implémentation :
- stocker la donnée,
- modifier le composant,
- ajouter une logique de rafraîchissement,
- créer une requête,
- revoir le modèle.
Ce n’est pas forcément faux mais ce n’est pas toujours le bon niveau pour un ticket produit. Une formulation plus utile consiste à se demander : qu’est-ce que l’utilisateur doit pouvoir faire, voir ou vérifier ? Par exemple, plutôt que d’écrire conserver la donnée dans la base après validation. On peut écrire : Retrouver une information saisie après validation du formulaire. Ou encore : Afficher la donnée saisie dans l’écran récapitulatif. Ce changement de formulation paraît minime mais il recentre le ticket sur l’usage et non sur la mécanique.
Des critères d’acceptation simples, mais testables
Les critères d’acceptation ont parfois mauvaise réputation. Ils donnent l’impression de faire “très process” ou de rallonger les tickets. Pourtant, bien utilisés, ils sont surtout là pour répondre à une question très concrète : qu’allons-nous vérifier pour dire que le ticket est validé ?
Si personne ne sait comment tester le résultat, il y a de fortes chances que le ticket soit encore trop flou. Quelques exemples de critères d’acceptation utiles :
- la donnée saisie reste visible après enregistrement ;
- le filtre n’affiche que les éléments correspondant au critère choisi ;
- un message explicite s’affiche si aucun résultat n’est trouvé ;
- le comportement attendu est identique sur desktop et mobile.
Pas besoin d’en écrire dix à chaque fois. Le sujet n’est pas la quantité c’est le caractère vérifiable. Dans le cas de demandes plus métier, on prendra soin d’écrire des critères d’acceptation sous forme de vrais cas de tests, avec des vrais jeux de données.
Quand faut-il découper un ticket ?
A partir de quand un ticket devient-il trop “gros” ? Il n’y a pas de règle magique mais un repère simple aide souvent.
Si un ticket contient en réalité deux verbes d’action bien distincts, il mérite peut-être d’être séparé. Par exemple :
- afficher les données
- filtrer les données
Dans certains cas, cela peut rester un seul ticket. Dans d’autres, le découpage apportera plus de clarté, plus de souplesse et de meilleures estimations. Le bon test est assez concret : si le ticket devient difficile à écrire, difficile à estimer ou difficile à tester, il est probablement trop gros.
Pour aller plus loin dans la qualité de vos tickets
1. S’appuyer sur des exemples réalistes
Autre enseignement utile : quand vous rédigez un ticket ou ses critères d’acceptation, il est souvent préférable de vous appuyer sur des cas réalistes. Pas forcément des données sensibles, bien sûr mais des cas qui ressemblent à la vraie vie du produit. Pourquoi ? Parce que les exemples trop abstraits cachent souvent les vrais irritants :
- longueurs de champ,
- cas limites,
- formats inattendus,
- combinaisons inhabituelles,
- états vides ou incomplets.
Un ticket gagne en qualité quand il anticipe la réalité d’usage plutôt qu’un cas théorique parfait
2. Éviter d’alourdir son backlog inutilement
C’est un point important à rappeler. Le but n’est pas de transformer chaque ticket en document de cadrage. Votre travail n’est pas de produire de la paperasse. Votre travail, c’est de faire avancer un produit. Donc non, il ne faut pas alourdir systématiquement les tickets. En revanche, un backlog devient beaucoup plus utile quand les tickets contiennent juste assez d’éléments pour :
- être compris,
- être priorisés,
- être développés,
- et être testés sans ambiguïté.
L’objectif n’est pas d’écrire plus. L’objectif est d’écrire mieux.
3. Définir une règle de passage avant le développement
Une idée intéressante c’est la notion de règle de passage. A quelles conditions un ticket peut-il quitter l’inbox et entrer réellement dans le backlog actif ? Par exemple, pour un bug :
- le constat est clair ;
- la procédure est connue ;
- la situation désirée est formulée ;
- la façon de tester est identifiée.
Et pour une évolution :
- le besoin produit est compréhensible ;
- le titre reste lisible pour quelqu’un de non technique ;
- les critères d’acceptation sont testables ;
- le niveau de découpage est raisonnable.
Ce type de règle ne sert pas à rigidifier. Il sert à éviter que des tickets trop flous avancent simplement “par habitude”
Ce que cela change pour un PM ou un PO
Mieux écrire ses tickets produit n’est pas seulement un sujet de backlog. C’est aussi un sujet de posture. Quand on connaît très bien le produit, et parfois très bien la technique, on a naturellement tendance à penser vite en termes de solution. Le travail consiste alors à remonter d’un cran :
- reformuler le besoin,
- revenir à un langage produit,
- expliciter le résultat attendu,
- poser un cadre de validation clair.
C’est un exercice moins simple qu’il n’en a l’air. Mais c’est aussi celui qui permet à un PM ou à un PO de mieux jouer son rôle :
clarifier ce qu’on cherche à obtenir, sans enfermer trop tôt l’équipe dans le comment.
Si vous avez l’impression que vos tickets deviennent vite flous, trop techniques ou trop dépendants du contexte oral, ce n’est pas un détail. C’est souvent le signe qu’un travail de clarification produit vaut le coup. Et la bonne nouvelle, c’est qu’il ne faut pas forcément tout révolutionner. Parfois, il suffit déjà de mieux distinguer bug et évolution, de reformuler quelques titres, et de rendre les critères d’acceptation un peu plus concrets. C’est souvent là que les discussions changent. Et avec elles, la qualité du backlog.
L'auteur
Romain Couturier
J’aide les équipes à mieux organiser leur travail pour gagner en fluidité et en efficacité au quotidien. Ce que j’aime le plus, c’est explorer les dynamiques de groupe et transmettre des outils qui rendent le travail plus clair et collaboratif. Si vous voulez en discuter ou découvrir mes partages, connectez-vous avec moi sur LinkedIn !
Plus d'articles
Découvrez nos formations :
Facilitation graphique
5 modules pour découvrir la pensée visuelle : des exercices, des échanges en live et une communauté soudée !
Sketchnoter sur tablette
Vous pratiquez la pensée visuelle sur papier et vous envisagez de passer au numérique ? Cette formation vous guide pas à pas.
IA4Product
Un bootcamp pour les responsables produit qui veulent améliorer leur quotidien avec l’IA.