Del PRD al backlog: generar incidencias planificadas con IA sin perder el hilo hacia el requisito
Convierte un PRD en incidencias dimensionadas y etiquetadas con IA: qué darle, cómo ligar cada incidencia a su requisito y qué rechazar antes de que entre al backlog.
En esta página
Para generar un backlog a partir de un PRD con IA, dale al agente una versión congelada de los requisitos, pídele incidencias que nombren cada una el requisito que implementan, que lleven los criterios de aceptación copiados de él y que sean lo bastante pequeñas para una persona en un ciclo, y rechaza toda incidencia que falle una de esas tres pruebas antes de que nada entre en el backlog. El agente es bueno en la parte tediosa, dividir y etiquetar; tú eres el único control de si la división sigue sumando el documento.
Este es el proceso que usamos en Atrix para nuestro propio producto, donde el agente escribe incidencias planificadas a partir de una base de requisitos y una persona las aprueba. Funciona con cualquier agente que pueda leer un documento y crear incidencias, y las reglas de rechazo son la parte útil sea cual sea tu herramienta.
Por qué importa el hilo hacia el requisito
Un backlog generado desde un PRD parece terminado el primer día: cuarenta incidencias, títulos limpios, etiquetas ordenadas. Dos ciclos después alguien pregunta "¿construimos el límite de exportación?" y nadie sabe decirlo, porque la incidencia que lo cubría se dividió, se renombró y se fusionó con otra, y el PRD se editó dos veces entre medias.
El hilo de cada incidencia hacia el requisito exacto que implementa es lo que permite responder esa pregunta. También es lo que permite a un agente, o a una persona, hacer una comprobación de cobertura después: qué requisitos no tienen incidencia, qué incidencias no apuntan a ningún requisito y qué requisitos cambiaron después de que se escribieran sus incidencias. Sin el hilo, la "cobertura" es una sensación.
Así que la primera regla es: congela el PRD antes de generar y haz que cada incidencia cite un requisito por su id.
Prepara el PRD antes de entregarlo
Un agente convertirá fielmente un PRD vago en incidencias vagas. Treinta minutos en el documento ahorran un día de limpieza de tickets:
- Numera los requisitos. R1, R2, R3, o un esquema anidado. El agente necesita un asidero estable que citar. Los párrafos en prosa no son asideros.
- Da criterios de aceptación a cada requisito. De dos a cuatro líneas en forma "dado / cuando / entonces" o una lista simple. Si no puedes escribir criterios para un requisito, no está listo para ser una incidencia, y el agente los inventará.
- Marca los no-objetivos. Una lista corta de lo que queda fuera evita que el agente genere incidencias para cosas que deliberadamente no haces.
- Congélalo. Guarda una versión, márcala como base y genera solo desde esa versión. Las ediciones posteriores producen una nueva base y un delta, no cambios silenciosos en incidencias ya en marcha.
Nuestra plantilla de PRD tiene estas secciones en este orden exactamente por esta razón.
El brief para el agente
El brief es corto y estricto. El nuestro, ligeramente editado:
Entrada: PRD "Recordatorios de reservas" v3 (base congelada). Requisitos R1–R9,
cada uno con criterios de aceptación. La sección de no-objetivos es vinculante.
Produce incidencias planificadas tales que:
- Cada incidencia nombra exactamente un id de requisito que implementa.
- Cada incidencia copia literalmente los criterios de aceptación de ese
requisito y añade después los criterios técnicos que hagan falta.
- Cada incidencia es lo bastante pequeña para que una persona la termine en
un ciclo; si un requisito necesita más, divídelo y di cómo se combinan.
- Cada incidencia lleva una etiqueta de tipo (feature, bug, chore) y una
etiqueta de área de la lista existente; no crees etiquetas.
- Ninguna incidencia implementa un no-objetivo.
- Lista los requisitos que no pudiste convertir en incidencias y di por qué.
Crea solo incidencias planificadas. No cambies incidencias ni estados existentes.
La última línea se corresponde con los permisos del agente. Las ejecuciones de planificación reciben work.write para crear incidencias planificadas y nada que toque el tablero en vivo.
Qué aspecto tiene una buena incidencia generada
| Campo | Bien | Rechazar |
|---|---|---|
| Título | "Enviar correo recordatorio 24 h antes de la reserva (R3)" | "Recordatorios" |
| Requisito | R3 | Ninguno, o "R3, R4, R5" |
| Criterios de aceptación | Los de R3 literales, más "reintenta una vez si falla SMTP" | "Funciona como se espera" |
| Tamaño | Una persona, menos de un ciclo | "Construir el sistema de recordatorios" |
| Etiquetas | feature, calendar | Una etiqueta nueva inventada por el agente |
| Dependencias | "Después de #212 (almacenamiento de plantillas)" | Sin indicar |
La tabla sirve también de lista de revisión. Revisar cuarenta incidencias contra seis columnas lleva unos cuarenta minutos, menos que escribirlas y mucho menos que descubrir los huecos después.
Reglas de rechazo: qué no aceptar en el backlog
Rechaza, y devuelve al agente con el motivo:
- Sin id de requisito. El fallo más común. La incidencia puede ser sensata, pero no puedes rastrearla. O implementa un requisito (cítalo), o es una tarea de mantenimiento (etiquétala así), o es ampliación de alcance (descártala).
- Varios ids de requisito en una incidencia. Eso es una épica, no una incidencia. Divide.
- Criterios de aceptación parafraseados en vez de copiados. La paráfrasis deriva. Los criterios de la incidencia deben ser los del PRD, más añadidos técnicos marcados claramente como añadidos.
- "Funciona correctamente" o "según diseño" como criterio. No es comprobable. Rechaza.
- Incidencias para no-objetivos. El agente leyó los no-objetivos y las generó igual. Pasa; rechaza.
- Un tamaño que no puedes imaginar a una persona terminando en un ciclo. Si tú no ves el final, la persona asignada tampoco.
- Etiquetas o componentes inventados. El agente debe usar la lista de etiquetas que recibió. Las etiquetas nuevas son una decisión humana.
Dos rondas suelen bastar. Si la tercera sigue produciendo los mismos fallos, el problema es el PRD, no el agente.
Planificar las incidencias en ciclos y etiquetas
Una vez que las incidencias pasan, son trabajo planificado, no comprometido. En Atrix, la gestión de proyectos las mantiene en el backlog hasta que se planifica un ciclo; un ciclo dura de una a cuatro semanas con un objetivo y un burndown que cuenta incidencias, y cuando un ciclo se cierra, las incidencias sin terminar pasan al siguiente o vuelven al backlog. No hay puntos de historia: la regla de tamaño de arriba ("una persona, un ciclo") es todo el modelo de estimación, y es deliberadamente gruesa.
Las etiquetas pertenecen al espacio de trabajo y tienen color. Usamos una etiqueta de tipo y una de área por incidencia, que es lo que el brief le dijo al agente que aplicara. Los hitos agrupan incidencias entre ciclos cuando un conjunto de requisitos tiene fecha de entrega.
La auditoría de requisitos compara después lo entregado con la base congelada e informa de cobertura y deriva: qué requisitos tienen incidencias entregadas, cuáles no tienen ninguna, cuáles cambiaron después de que se escribieran sus incidencias. Compara requisitos con el plan, no con el código; si el código hace lo que dice la incidencia sigue siendo cosa de la revisión de código.
El mismo flujo en Linear o Jira: los proyectos y etiquetas de Linear, las épicas y componentes de Jira. El hilo hacia el requisito es una convención en esas herramientas, no una función, así que pon el id del requisito en el título de la incidencia y guarda el PRD en un sitio con historial de versiones.
Preguntas frecuentes
¿Puede la IA generar un backlog a partir de un PRD?
Sí, y hace bien la división y el etiquetado si el PRD tiene requisitos numerados con criterios de aceptación y una lista de no-objetivos. No juzga si la división suma, así que cada incidencia generada necesita una comprobación humana contra una lista corta de rechazo antes de entrar en el backlog.
¿Cómo deben enlazar las incidencias generadas con los requisitos?
Cada incidencia nombra exactamente un id de requisito y copia literalmente sus criterios de aceptación. El PRD se congela como base antes de generar, de modo que las ediciones posteriores producen una nueva base en vez de cambiar en silencio incidencias en marcha.
¿Qué tamaño debe tener una incidencia generada?
Lo bastante pequeña para que una persona la termine dentro de un ciclo. Si un requisito necesita más, divídelo e indica cómo se combinan las partes. Esta regla gruesa sustituye a los puntos de historia; Atrix no tiene puntos por diseño y el burndown cuenta incidencias.
¿Qué debo rechazar de un backlog generado por IA?
Incidencias sin id de requisito, incidencias que citan varios requisitos, criterios de aceptación parafraseados o no comprobables, incidencias para no-objetivos declarados, incidencias demasiado grandes para imaginar su fin y etiquetas inventadas. Devuelve cada una con el motivo; dos rondas suelen bastar.
¿Qué es un backlog de producto?
La lista ordenada de trabajo planificado que aún no se ha programado en un ciclo. Consulta la entrada del glosario sobre backlogs para ver en qué se diferencia de un roadmap y de un ciclo.
¿La auditoría de requisitos comprueba el código?
No. Compara las incidencias entregadas con la base congelada de requisitos e informa de cobertura y deriva. Si el código hace lo que dice la incidencia es una revisión de código, hecha por personas.
Siguiente paso
Numera los requisitos de tu próximo PRD, añade criterios de aceptación a cada uno y congélalo antes de pedir incidencias a cualquier agente. La plantilla de PRD está organizada para esto, y la página del agente de IA muestra qué devuelve una ejecución Develop: requisitos, arquitectura e incidencias planificadas, cada una apuntando a su requisito.