Du PRD au backlog : générer des tickets avec l'IA

Pour générer un backlog à partir d'un PRD avec l'IA, donnez à l'agent une version gelée des exigences, demandez des tickets qui nomment chacun l'exigence qu'ils implémentent, reprennent ses critères d'acceptation tels quels et sont assez petits pour une personne en un cycle, puis rejetez tout ticket qui échoue à l'un de ces trois tests avant que quoi que ce soit n'entre dans le backlog. L'agent est bon pour la partie fastidieuse, découper et étiqueter ; vous êtes le seul contrôle sur le fait que le découpage reconstitue bien le document.

C'est le processus que nous utilisons chez Atrix pour notre propre produit, où l'agent écrit des tickets planifiés à partir d'une référence d'exigences et où un humain les approuve. Il fonctionne avec tout agent capable de lire un document et de créer des tickets, et les règles de rejet sont la partie utile quel que soit votre outil.

Pourquoi le fil vers l'exigence compte

Un backlog généré depuis un PRD a l'air terminé le premier jour : quarante tickets, titres propres, étiquettes nettes. Deux cycles plus tard, quelqu'un demande « a-t-on construit la limite d'export ? » et personne ne sait répondre, parce que le ticket qui la couvrait a été scindé, renommé et fusionné avec un autre, et que le PRD a été édité deux fois entre-temps.

Le fil de chaque ticket vers l'exigence exacte qu'il implémente est ce qui permet de répondre. C'est aussi ce qui permet à un agent, ou à une personne, de faire plus tard une vérification de couverture : quelles exigences n'ont aucun ticket, quels tickets ne pointent vers aucune exigence, quelles exigences ont changé après l'écriture de leurs tickets. Sans le fil, la « couverture » est une impression.

Donc la première règle : gelez le PRD avant de générer, et faites citer à chaque ticket une exigence par son identifiant.

Préparer le PRD avant de le confier

Un agent transformera fidèlement un PRD vague en tickets vagues. Trente minutes sur le document épargnent une journée de nettoyage de tickets :

Numérotez les exigences. R1, R2, R3, ou un schéma imbriqué. L'agent a besoin d'une poignée stable à citer. Des paragraphes de prose ne sont pas des poignées.
Donnez des critères d'acceptation à chaque exigence. Deux à quatre lignes en « étant donné / quand / alors » ou une simple liste. Si vous ne pouvez pas écrire de critères pour une exigence, elle n'est pas prête à devenir un ticket, et l'agent en inventera.
Marquez les non-objectifs. Une courte liste de ce qui est hors périmètre empêche l'agent de générer des tickets pour ce que vous ne faites délibérément pas.
Gelez-le. Enregistrez une version, étiquetez-la comme référence et générez seulement à partir d'elle. Les modifications ultérieures produisent une nouvelle référence et un delta, pas des changements silencieux sur des tickets déjà en cours.

Notre modèle de PRD a ces sections dans cet ordre exactement pour cette raison.

Le brief pour l'agent

Le brief est court et strict. Le nôtre, légèrement édité :

Entrée : PRD « Rappels de réservation » v3 (référence gelée). Exigences R1–R9,
chacune avec critères d'acceptation. La section non-objectifs est contraignante.

Produis des tickets planifiés tels que :
- Chaque ticket nomme exactement un identifiant d'exigence qu'il implémente.
- Chaque ticket reprend mot pour mot les critères d'acceptation de cette
  exigence, puis ajoute les critères techniques nécessaires.
- Chaque ticket est assez petit pour qu'une personne le termine en un cycle ;
  si une exigence en demande plus, scinde-la et dis comment les parties se combinent.
- Chaque ticket porte une étiquette de type (feature, bug, chore) et une
  étiquette de domaine issue de la liste existante ; ne crée pas d'étiquettes.
- Aucun ticket n'implémente un non-objectif.
- Liste les exigences que tu n'as pas pu transformer en tickets et dis pourquoi.

Crée uniquement des tickets planifiés. Ne modifie ni tickets ni statuts existants.

La dernière ligne correspond aux permissions de l'agent. Les exécutions de planification reçoivent work.write pour créer des tickets planifiés et rien qui touche le tableau en cours.

À quoi ressemble un bon ticket généré

Champ	Bon	À rejeter
Titre	« Envoyer le courriel de rappel 24 h avant la réservation (R3) »	« Rappels »
Exigence	R3	Aucune, ou « R3, R4, R5 »
Critères d'acceptation	Ceux de R3 mot pour mot, plus « réessaie une fois en cas d'échec SMTP »	« Fonctionne comme prévu »
Taille	Une personne, moins d'un cycle	« Construire le système de rappels »
Étiquettes	feature, calendar	Une nouvelle étiquette inventée par l'agent
Dépendances	« Après #212 (stockage des modèles) »	Non indiquées

Le tableau sert aussi de liste de relecture. Relire quarante tickets sur six colonnes prend environ quarante minutes, moins que les écrire et bien moins que découvrir les trous plus tard.

Règles de rejet : ce qu'il ne faut pas accepter dans le backlog

Rejetez, et renvoyez à l'agent avec la raison :

Pas d'identifiant d'exigence. L'échec le plus courant. Le ticket est peut-être sensé, mais vous ne pouvez pas le tracer. Soit il implémente une exigence (citez-la), soit c'est une corvée (étiquetez-la ainsi), soit c'est une dérive de périmètre (abandonnez).
Plusieurs identifiants d'exigence sur un ticket. C'est une epic, pas un ticket. Scindez.
Des critères d'acceptation paraphrasés au lieu de copiés. La paraphrase dérive. Les critères du ticket doivent être ceux du PRD, plus des ajouts techniques clairement marqués comme tels.
« Fonctionne correctement » ou « conforme à la conception » comme critère. Non testable. Rejetez.
Des tickets pour des non-objectifs. L'agent a lu les non-objectifs et les a générés quand même. Ça arrive ; rejetez.
Une taille que vous n'arrivez pas à imaginer finie par une personne en un cycle. Si vous ne voyez pas la fin, la personne assignée non plus.
Étiquettes ou composants inventés. L'agent doit utiliser la liste d'étiquettes fournie. Les nouvelles étiquettes sont une décision humaine.

Deux tours suffisent en général. Si le troisième produit encore les mêmes échecs, le problème est le PRD, pas l'agent.

Planifier les tickets en cycles et étiquettes

Une fois les tickets acceptés, ils sont du travail planifié, pas engagé. Dans Atrix, la gestion de projet les garde dans le backlog jusqu'à la planification d'un cycle ; un cycle dure d'une à quatre semaines avec un objectif et un burndown qui compte les tickets, et à la clôture d'un cycle, les tickets inachevés passent au suivant ou retournent au backlog. Il n'y a pas de story points : la règle de taille ci-dessus (« une personne, un cycle ») est tout le modèle d'estimation, et elle est volontairement grossière.

Les étiquettes appartiennent à l'espace de travail et portent une couleur. Nous utilisons une étiquette de type et une de domaine par ticket, ce que le brief a demandé à l'agent d'appliquer. Les jalons regroupent des tickets à travers les cycles quand un ensemble d'exigences a une date de livraison.

L'audit d'exigences compare ensuite ce qui a été livré à la référence gelée et rapporte couverture et dérive : quelles exigences ont des tickets livrés, lesquelles n'en ont aucun, lesquelles ont changé après l'écriture de leurs tickets. Il compare les exigences au plan, pas au code ; savoir si le code fait ce que dit le ticket reste une revue de code.

Le même flux dans Linear ou Jira : projets et étiquettes de Linear, epics et composants de Jira. Le fil vers l'exigence y est une convention plutôt qu'une fonction, donc mettez l'identifiant de l'exigence dans le titre du ticket et gardez le PRD dans un endroit avec historique des versions.

FAQ

L'IA peut-elle générer un backlog à partir d'un PRD ?

Oui, et elle découpe et étiquette bien si le PRD a des exigences numérotées avec critères d'acceptation et une liste de non-objectifs. Elle ne juge pas si le découpage reconstitue le tout, donc chaque ticket généré doit passer un contrôle humain sur une courte liste de rejet avant d'entrer dans le backlog.

Comment les tickets générés doivent-ils renvoyer aux exigences ?

Chaque ticket nomme exactement un identifiant d'exigence et reprend mot pour mot ses critères d'acceptation. Le PRD est gelé comme référence avant la génération, de sorte que les modifications ultérieures produisent une nouvelle référence plutôt que de changer silencieusement des tickets en cours.

Quelle taille doit avoir un ticket généré ?

Assez petite pour qu'une personne le termine en un cycle. Si une exigence en demande plus, scindez-la et indiquez comment les parties se combinent. Cette règle grossière remplace les story points ; Atrix n'a pas de points par conception, et le burndown compte les tickets.

Que rejeter d'un backlog généré par l'IA ?

Les tickets sans identifiant d'exigence, ceux qui citent plusieurs exigences, les critères paraphrasés ou non testables, les tickets pour des non-objectifs déclarés, les tickets trop gros pour en imaginer la fin, et les étiquettes inventées. Renvoyez chacun avec la raison ; deux tours suffisent en général.

Qu'est-ce qu'un backlog produit ?

La liste ordonnée du travail planifié pas encore programmé dans un cycle. Voir l'entrée du glossaire sur les backlogs pour la différence avec une roadmap et un cycle.

L'audit d'exigences vérifie-t-il le code ?

Non. Il compare les tickets livrés à la référence gelée des exigences et rapporte couverture et dérive. Savoir si le code fait ce que dit le ticket est une revue de code, faite par des personnes.

Prochaine étape

Numérotez les exigences de votre prochain PRD, ajoutez des critères d'acceptation à chacune et gelez-le avant de demander des tickets à un agent. Le modèle de PRD est organisé pour cela, et la page de l'agent IA montre ce qu'une exécution Develop renvoie : exigences, architecture et tickets planifiés, chacun pointant vers son exigence.

Du PRD au backlog : générer des tickets planifiés avec l'IA sans perdre le fil vers l'exigence