Listas de verificación, subtareas o casillas en la descripción — elige la forma adecuada

¿Cuáles son las tres formas de una lista en Jira?

Las casillas nativas en la descripción (y los action items) son una lista puntual en el elemento de trabajo. Las subtareas son incidencias hijas con asignatario, estimación, fecha de vencimiento y workflow propios. Checklist for Jira deja una lista estructurada en el padre — plantillas, progreso, validadores — sin crear incidencias extra. La guía de listas de verificación en Jira recorre cómo añadir esa lista; esta página es la guía de decisión.

Ninguna es un apaño. Los tres pasos de verificación de un reporter van en la descripción. Un pase de diseño de otro equipo merece una subtarea. Definition of Done, una lista de verificación de pruebas QA y un runbook de release van en el padre como listas de verificación para que el listón de calidad viaje con la story.

Por qué elegir a propósito

Cuando cada fila de “¿nos acordamos?” se convierte en una subtarea, el tablero se llena de tarjetas que nunca debieron ser incidencias. Cuando el listón de calidad vive solo en Confluence, es fácil saltárselo. Una lista de verificación en el elemento de trabajo es el término medio: los mismos pasos cada vez, progreso en la incidencia y en JQL, y un solo padre para el trozo de trabajo.

Usar las tres bien es un acierto. El intake se queda ligero. La entrega conserva un listón de envío compartido. Los trozos reales de trabajo siguen mereciendo una incidencia hija. Checklist for Jira está hecho para las listas que repites; Jira ya cubre el resto.

Cuándo usar cada una

Usa casillas en la descripción para una lista que no vas a reutilizar. Usa una lista de verificación cuando los mismos pasos aparecen en cada story, bug o cambio — sobre todo si quieres plantillas, una barra de progreso o una puerta de workflow. Abre una subtarea cuando el trabajo es un trozo de verdad: owner, estimación y estado propios en el tablero.

Lado a lado

Cuándo las subtareas son la herramienta correcta

Crea una subtarea cuando el trabajo es un trozo real, no una comprobación de calidad. Un pase de diseño de otro equipo, un job de migración de datos con su propia estimación, una revisión de seguridad con un workflow aparte — eso merece una incidencia hija. Las listas de verificación no sustituyen eso. Sustituyen la docena de filas de “¿nos acordamos?” que nunca debieron ser incidencias.

Cuándo una lista de verificación en el padre encaja mejor

Deja Definition of Done y los acceptance criteria como listas de verificación en la story para que el listón de envío y el comportamiento prometido se vean juntos. Adjunta una lista de verificación de pruebas QA cuando los testers poseen un pase. Usa una plantilla Protected cuando el texto debe quedarse fijo. Aplícalas y exígelas con la guía de automatización para que el proceso aparezca sin tarjetas extra en el tablero.

Ejemplos de entrega, QA y onboarding

• Entrega: deja Definition of Done y los acceptance criteria como listas de verificación en la story. Separa una investigación de rendimiento en una subtarea con su propio owner.
• QA: ejecuta la lista de verificación de pruebas QA en el padre. Abre una subtarea solo cuando un fallo necesita un fixer y un workflow aparte.
• Onboarding: una lista de verificación Protected en el ticket de contratación basta para cuentas, hardware y presentaciones. Una subtarea es correcta cuando IT debe seguir un pedido de portátil como pieza de trabajo propia.

Combínala con el resto del set de delivery

Cuando quieras reutilizar una lista, empieza en el hub de plantillas y conéctala con la guía de automatización. La guía de listas de verificación en Jira cubre las opciones nativas y cómo añadir una lista de verificación. Deja las subtareas para el trabajo que merece una incidencia; deja las listas de verificación para el proceso que debe quedarse en el padre.

Preguntas frecuentes