Un flujo de trabajo de Jira para el desarrollo de software es el camino que sigue cada historia, bug y tarea desde la idea hasta producción. Cuando ese camino coincide con la forma real de trabajar del equipo, el tablero se convierte en una imagen fiable de la entrega: cualquiera puede ver qué está bloqueado, qué espera revisión y qué está listo para publicarse. Cuando no coincide, los desarrolladores pierden el tiempo arrastrando tarjetas, los responsables persiguen actualizaciones de estado y los informes no dicen nada útil.
La mayoría de los proyectos de Jira que heredamos de clientes tienen el segundo problema. Los flujos de trabajo crecen estado a estado hasta que nadie sabe explicarlos, y el mismo tipo de incidencia se comporta de forma distinta en cada equipo. Cuando asumimos la entrega como parte de nuestros equipos gestionados de ingeniería de producto, ordenar el flujo de trabajo de Jira suele ser una de las tareas de las dos primeras semanas, porque todas las métricas posteriores dependen de él.
Esta guía explica qué es un flujo de trabajo de Jira, qué flujo encaja con la mayoría de los equipos de software, cinco ejemplos que puede copiar, cómo configurarlo, cómo automatizar las transiciones desde GitHub, GitLab o Bitbucket, y las buenas prácticas y errores que deciden si Jira le ayuda o le frena. Se aplica a Jira Cloud y a Jira Data Center.
¿Qué es un flujo de trabajo de Jira para el desarrollo de software?
Un flujo de trabajo de Jira es el conjunto de estados en los que puede estar una incidencia y las transiciones que la mueven entre ellos. En el desarrollo de software modela la vida de un elemento de trabajo: desde el backlog, pasando por la programación, la revisión de código y las pruebas, hasta el lanzamiento. Todo proyecto de Jira usa un flujo de trabajo, tanto si el equipo lo diseñó como si aceptó el predeterminado.
El flujo de trabajo no es el tablero. El flujo de trabajo define qué estados existen y qué movimientos están permitidos; el tablero es una vista que asigna esos estados a columnas. Puede tener varios tableros sobre un mismo flujo de trabajo, y puede ocultar o agrupar estados en una columna sin modificar el flujo subyacente.
Los componentes de un flujo de trabajo de Jira
Todo flujo de trabajo de Jira se compone de seis elementos, y entenderlos facilita mucho diseñar uno limpio.
| Componente | Qué hace | Ejemplo en desarrollo de software |
|---|---|---|
| Estado | La situación actual de una incidencia | In Progress, In Review, Done |
| Categoría de estado | Agrupa los estados en To Do, In Progress o Done para los informes | «In QA» pertenece a la categoría In Progress |
| Transición | Un movimiento permitido de un estado a otro | In Review → In QA |
| Condición | Quién o qué puede ver y usar una transición | Solo el responsable asignado puede iniciar el trabajo |
| Validador | Una comprobación que debe superarse antes de completar el movimiento | Debe haber un pull request vinculado antes de la revisión |
| Post function / regla | Una acción que se ejecuta después del movimiento | Fijar la resolución en «Done» y avisar a QA |
Los proyectos gestionados por la empresa (company-managed) exponen directamente las condiciones, los validadores y las post functions. Los proyectos gestionados por el equipo (team-managed) ofrecen reglas de transición más sencillas para restringir, validar y actuar sobre las transiciones. Ambos pueden ampliarse con Jira Automation.
Esquemas de flujo de trabajo y tipos de incidencia
Un esquema de flujo de trabajo asigna tipos de incidencia a flujos de trabajo dentro de un proyecto. Así es como un proyecto puede usar un flujo para historias y tareas y otro distinto para bugs. Compartir un mismo esquema entre varios proyectos es la principal herramienta para mantener la coherencia entre muchos equipos, como veremos en la sección sobre escalado.
¿Cuál es el mejor flujo de trabajo de Jira para el desarrollo de software?
El mejor flujo de trabajo de Jira para el desarrollo de software es el más sencillo que aún muestra dónde espera el trabajo. Para la mayoría de los equipos de producto eso significa seis estados: Backlog, Selected for Development, In Progress, In Review, In QA y Done. Cada estado responde a una pregunta sobre el trabajo, y cada uno tiene un responsable y una regla de salida acordada por todos.
| Estado | Categoría | Responsable | Regla de salida (Definition of Ready / Done del paso) |
|---|---|---|---|
| Backlog | To Do | Product owner | Tiene un objetivo claro, criterios de aceptación y una estimación |
| Selected for Development | To Do | Product owner + equipo | Incorporada al sprint o a la cola de lo siguiente por hacer |
| In Progress | In Progress | Desarrollador | Código terminado, pruebas escritas y pull request abierto |
| In Review | In Progress | Revisor | Pull request aprobado y fusionado; la CI está en verde |
| In QA | In Progress | Ingeniero de QA | Criterios de aceptación verificados en staging, sin bugs bloqueantes |
| Done | Done | Equipo | Publicada o lista para publicarse tras un feature flag; con la resolución fijada |
Dos reglas hacen que este flujo de trabajo funcione. Primera: permita los movimientos hacia atrás; la revisión y QA deben poder devolver una incidencia a In Progress sin ayuda del administrador. Segunda: deje «Blocked» fuera de la lista de estados y use una marca (flag) en su lugar. Un estado de bloqueo oculta dónde estaba el trabajo cuando se atascó, mientras que una marca mantiene la incidencia en su columna real y sigue mostrando el problema.
¿Cuántos estados debe tener un flujo de trabajo de Jira?
Un equipo de software típico necesita de 5–7 estados. Con menos de cinco, la revisión o las pruebas suelen quedar ocultas, de modo que el trabajo aparece «en curso» durante días sin ninguna señal del porqué. Con más de siete, suele haber estados que describen personas o departamentos en lugar de la situación del trabajo. Una prueba útil: si el equipo no puede explicar un estado en una frase, o ninguna incidencia ha pasado por él en el último mes, elimínelo.
5 ejemplos de flujos de trabajo de Jira para el desarrollo de software
Cada tipo de trabajo necesita un flujo ligeramente distinto, pero todos deberían compartir la misma columna vertebral. Estos cinco ejemplos de flujos de trabajo de Jira cubren casi cualquier equipo de software; copie el más parecido a su proceso y ajuste solo lo que pueda justificar.
1. Flujo básico para equipos pequeños
To Do → In Progress → In Review → Done. Se parece mucho al flujo predeterminado de Jira y funciona para equipos de dos a cinco desarrolladores que prueban su propio código o publican tras feature flags. Añada un estado de QA en cuanto se incorpore un tester dedicado; de lo contrario, las pruebas se vuelven invisibles.
2. Flujo de trabajo Scrum
Backlog → Selected for Development → In Progress → In Review → In QA → Done. El alcance del sprint vive en Selected for Development, y el tablero del sprint muestra los cuatro estados de trabajo. Los informes de burndown y de velocidad dependen de que Done signifique «cumple la Definition of Done», así que nunca deje que una incidencia llegue a Done antes de pasar por QA. Nuestra guía de desarrollo de software con Scrum explica los roles y eventos que hay detrás de este flujo.
3. Flujo de trabajo Kanban
Backlog → Ready → In Progress → Review → Testing → Ready to Release → Done. A los equipos Kanban les importa el flujo, así que añaden un búfer «Ready to Release» y fijan límites WIP en las columnas del tablero, por ejemplo tres incidencias en curso por desarrollador. El cycle time y el diagrama de flujo acumulado se convierten en las principales señales de salud. Consulte desarrollo de software con Kanban para orientarse sobre los límites WIP.
4. Flujo de seguimiento de bugs
Open → Triaged → In Progress → In Review → Verified → Closed, con resoluciones como Fixed, Duplicate, Cannot Reproduce y Won't Fix. El paso adicional Triaged garantiza que alguien revise la gravedad y la reproducibilidad antes de que un desarrollador tome el bug. La verificación (Verified) debe hacerla quien lo reportó o QA, no el desarrollador que lo corrigió.
5. Flujo de funcionalidades y lanzamientos con UAT
Idea → Discovery → Ready → In Development → In QA → UAT → Released. Encaja con épicas o funcionalidades de cara al cliente en las que un responsable de negocio da el visto bueno. A menudo se aplica a nivel de épica, mientras que las historias que contiene siguen el flujo Scrum o Kanban. El paso de UAT refleja el proceso descrito en nuestra guía de pruebas de aceptación de usuario.
| Flujo de trabajo | Ideal para | Estados | Métrica clave |
|---|---|---|---|
| Básico | Equipos pequeños sin QA dedicado | 4 | Throughput por semana |
| Scrum | Equipos de producto que trabajan por sprints | 6 | Compromiso del sprint frente a lo completado |
| Kanban | Entrega continua, soporte y equipos de plataforma | 7 | Cycle time, WIP |
| Seguimiento de bugs | Defectos procedentes de QA, del soporte y de los usuarios | 6 | Tiempo hasta el triaje, tiempo hasta la corrección |
| Funcionalidad con UAT | Épicas, aprobación del cliente y lanzamientos regulados | 7 | Lead time de la idea → al lanzamiento |
Cómo configurar un flujo de trabajo de Jira para el desarrollo de software en 8 pasos
Configurar un flujo de trabajo de Jira lleva una tarde de ajustes, pero debería empezar con una hora de pizarra. Diseñe primero el flujo en papel con el equipo, después constrúyalo en Jira y pruébelo con algunas incidencias reales antes de pasar a todo el mundo.
- Mapee el proceso real. Pregunte al equipo cómo avanza hoy realmente una historia, incluido dónde espera. Anote cada traspaso: de desarrollador a revisor, de revisor a QA y de QA al lanzamiento.
- Elija estados, no personas. Nombre cada estado según la situación del trabajo («In Review»), nunca según una persona o un equipo («With Anna», «Backend»). Apunte a 5–7.
- Asigne categorías de estado. Incluya cada estado en To Do, In Progress o Done. De ello dependen los informes, las hojas de ruta y el color de la incidencia.
- Dibuje las transiciones. Permita todos los movimientos hacia delante que necesite y los movimientos hacia atrás para el retrabajo. Evite «cualquier estado a cualquier estado», salvo para un reinicio reservado al administrador.
- Añada solo las reglas que necesite. Las habituales: un validador que exija un pull request vinculado antes de In Review, una condición para que solo QA pueda mover a Done y una post function que fije la resolución en Done y la borre al reabrir.
- Cree o actualice el esquema de flujo de trabajo. Asigne las historias, tareas y subtareas al flujo principal, y los bugs al flujo de bugs si lo utiliza. Publique primero el esquema en un proyecto de prueba.
- Configure el tablero. Asigne los estados a columnas, fije límites WIP para Kanban y añada filtros rápidos como «Flagged» o «Asignadas a mí».
- Haga un piloto y después despliéguelo. Trabaje un sprint con el nuevo flujo en un solo equipo, recoja los puntos de fricción, corríjalos y solo entonces migre los demás proyectos. Redacte una guía de una página que explique cada estado y su regla de salida.
¿Cómo debe conectarse un flujo de trabajo de Jira con Git, la revisión de código y CI/CD?
Un flujo de trabajo de Jira para el desarrollo de software debe moverse por los eventos de desarrollo, no arrastrando tarjetas a mano. Cuando las ramas, los pull requests, las builds y los despliegues actualizan las incidencias automáticamente, el tablero se mantiene exacto y los desarrolladores no salen de su editor.
- Vincúlelo todo con la clave de la incidencia. Ponga la clave, por ejemplo
PAY-142, en los nombres de las ramas, los mensajes de commit y los títulos de los pull requests. Jira mostrará entonces en la incidencia el panel de desarrollo con ramas, commits, pull requests, builds y despliegues. - Use los smart commits con moderación. Con Bitbucket y otras herramientas conectadas, mensajes de commit como
PAY-142 #comment fixed roundingoPAY-142 #time 2hactualizan Jira directamente. Los comandos de transición también funcionan, pero las reglas de automatización son más fáciles de gobernar. - Conecte GitHub o GitLab mediante las apps oficiales. GitHub for Jira y GitLab for Jira Cloud envían a Jira los datos de desarrollo y la información de despliegues, que también alimenta la vista de despliegues y el seguimiento de lanzamientos.
- Informe de builds y despliegues. Cuando CI/CD publica el estado de las builds y los despliegues, la incidencia muestra si su código está en staging o en producción, y Done puede significar «desplegado» en lugar de «fusionado».
Aquí es también donde el flujo de trabajo se encuentra con su pipeline de entrega. Si todavía lo está construyendo, nuestra guía de CI/CD en el desarrollo de software explica las etapas que deben informar a Jira.
¿Qué transiciones del flujo de trabajo de Jira conviene automatizar?
Automatice las transiciones que siguen a un evento predecible y deje el criterio humano donde haga falta una decisión. Una buena regla práctica: si la transición siempre ocurre cuando ocurre otra cosa, debe hacerla una regla; si alguien tiene que decidir, déjela manual.
| Disparador (Jira Automation) | Acción | Por qué ayuda |
|---|---|---|
| Creación de rama o primer commit | Mover la incidencia a In Progress y asignarla al autor | El tablero muestra la fecha real de inicio sin arrastrar a mano |
| Creación de un pull request | Mover a In Review y avisar al grupo de revisores | La cola de revisión se hace visible |
| Pull request fusionado | Mover a In QA y comentar con el enlace a la build | QA sabe exactamente qué debe probar |
| Pull request rechazado | Devolver a In Progress | El retrabajo se registra con honestidad |
| Despliegue correcto en producción | Mover a Done, fijar la resolución y la fix version | Done significa publicado; las notas de la versión siguen siendo exactas |
| Todas las subtareas terminadas | Mover la historia principal a In QA o Done | Elimina una fuente habitual de historias estancadas |
| Sin actualizaciones durante 5 días en In Review | Marcar la incidencia y avisar al revisor | Evita que los pull requests se queden olvidados |
Mantenga manuales las aprobaciones, el visto bueno de QA y el UAT. Las funciones de IA integradas de Atlassian ya pueden resumir incidencias y sugerir los siguientes pasos, pero un estado que representa una decisión de calidad debe moverlo la persona responsable de ella. La automatización es más eficaz cuando el propio flujo de trabajo ya está limpio; automatizar un flujo desordenado solo acelera el desorden.
Buenas prácticas del flujo de trabajo de Jira: una lista de comprobación de 7 puntos
Los mejores flujos de trabajo de Jira comparten los mismos hábitos: pocos estados, responsabilidades claras y revisión periódica. Use esta lista al diseñar un flujo nuevo o al auditar uno existente.
- Limítese a 5–7 estados y póngales nombre según la situación del trabajo.
- Dé a cada estado un responsable y una regla de salida recogidos en la guía de una página del proyecto.
- Haga explícito el retrabajo con transiciones hacia atrás, en lugar de reabrir tickets o crear duplicados.
- Use marcas y etiquetas para las situaciones secundarias, como bloqueado, pendiente de diseño o a la espera del cliente, en lugar de estados adicionales.
- Fije correctamente las resoluciones: toda incidencia en Done necesita una resolución, y al reabrirla debe borrarse; de lo contrario, los informes contarán como terminado un trabajo sin acabar.
- Comparta un único esquema de flujo de trabajo entre los equipos que construyen el mismo producto y permita variaciones locales solo a nivel de tablero.
- Revise el flujo de trabajo cada trimestre con el cycle time, el tiempo en cada estado y el diagrama de flujo acumulado.
Estos hábitos importan porque la fricción con las herramientas sale cara. El informe State of Developer Experience de Atlassian (2024) concluyó que el 69% de los desarrolladores pierde ocho o más horas a la semana por ineficiencias, y los procesos poco claros y las tareas de actualización de estados forman parte de esa factura. Para el conjunto más amplio de métricas de seguimiento, consulte nuestra guía de KPI de desarrollo de software y benchmarks DORA.
Errores habituales en los flujos de trabajo de Jira y cómo corregirlos
La mayoría de los flujos de trabajo de Jira defectuosos fallan de las mismas pocas maneras, y cada una tiene una solución sencilla. La tabla siguiente recoge los problemas que vemos con más frecuencia al auditar proyectos de clientes.
| Error | Síntoma | Solución |
|---|---|---|
| Demasiados estados | 12+ columnas, muchas siempre vacías | Agrupar en 5–7 y pasar las situaciones secundarias a marcas o etiquetas |
| Estados con nombres de personas o equipos | «Con backend», «Esperando a John» | Renombrar según la situación del trabajo; usar el responsable y los componentes para la propiedad |
| «Blocked» como estado | Es imposible saber dónde se detuvo el trabajo bloqueado | Usar la función de marca (flag) y un filtro rápido |
| Sin transiciones hacia atrás | Un QA fallido genera tickets nuevos o ediciones del administrador | Permitir In Review/In QA → In Progress |
| Falta la resolución en Done | Los informes y filtros muestran el trabajo terminado como abierto | Una post function o regla que fije y borre la resolución |
| Un flujo de trabajo por equipo para el mismo producto | Los informes entre equipos no cuadran | Un único esquema compartido; diferencias solo en los tableros |
| Solo actualizaciones manuales de estado | El tablero va días por detrás de la realidad | Automatizar a partir de los eventos de rama, PR, build y despliegue |
¿Cómo se escalan los flujos de trabajo de Jira a varios equipos?
Escale los flujos de trabajo de Jira con una columna vertebral común y libertad local solo donde no rompa los informes. Todos los equipos que trabajan en un mismo producto deberían usar los mismos estados y categorías de estado, para que una vista de cartera, un plan de lanzamientos o un panel entre equipos signifiquen lo mismo en todas partes.
- Un esquema de flujo de trabajo por línea de producto, compartido por todos sus proyectos y gestionado por un administrador de Jira o un pequeño grupo de trabajo.
- Un proyecto con varios tableros cuando los equipos trabajan sobre la misma base de código: cada equipo filtra su tablero por componente o por el campo de equipo, mientras el flujo de trabajo sigue siendo común.
- Variación local a nivel de tablero: los límites WIP, los carriles (swimlanes) y los filtros rápidos pueden variar de un equipo a otro sin tocar el flujo de trabajo.
- Un proceso de cambios: los cambios en el flujo de trabajo pasan por una breve solicitud justificada, se prueban en un proyecto sandbox y se anuncian antes de aplicarse.
- Limpieza periódica de estados, campos personalizados y flujos de trabajo inactivos que no se usan, porque ralentizan Jira y confunden a las nuevas incorporaciones del equipo.
El mismo principio se aplica cuando trabaja con un partner de entrega externo o con un equipo ampliado: deben trabajar dentro de su flujo de trabajo compartido, no en uno paralelo. Nuestra guía sobre gestión de equipos de desarrollo de software explica el ritmo operativo que lo rodea.
¿Cómo se audita un flujo de trabajo de Jira? Una revisión de salud trimestral
Audite el flujo de trabajo de Jira cada trimestre midiendo dónde esperan las incidencias, no cuántos estados existen. Tres informes integrados bastan para detectar la mayoría de los problemas, y la revisión completa lleva alrededor de una hora.
- Diagrama de flujo acumulado. Una banda que no deja de ensancharse revela un cuello de botella; por ejemplo, si se ensancha la banda de In Review, el cuello de botella está en las revisiones.
- Gráfico de control o informe de cycle time. Fíjese en la media y en los valores atípicos. Las incidencias que tardan el triple de la media suelen revelar requisitos poco claros o dependencias ocultas.
- Tiempo en cada estado. Los estados en los que las incidencias permanecen paradas durante días son candidatos a automatización, límites WIP o un cambio de proceso.
- Estados y transiciones sin uso. Todo lo que no se haya usado en el último trimestre puede eliminarse.
- Feedback del equipo. Pregunte qué transiciones esquiva la gente. Los atajos son la señal más honesta de que un flujo de trabajo ya no encaja.
Ideas clave
- Un flujo de trabajo de Jira es un conjunto de estados y transiciones; el tablero es solo una vista de él.
- El mejor flujo de trabajo de Jira para el desarrollo de software tiene de 5–7 estados, cada uno con un responsable y una regla de salida.
- Copie uno de los cinco patrones probados: básico, Scrum, Kanban, seguimiento de bugs o funcionalidad con UAT.
- Use marcas en lugar de un estado Blocked y permita siempre las transiciones hacia atrás para el retrabajo.
- Impulse las transiciones desde las ramas, los pull requests, las builds y los despliegues con Jira Automation.
- Comparta un único esquema de flujo de trabajo entre los equipos del mismo producto y revíselo cada trimestre.
Preguntas frecuentes
¿Qué es un flujo de trabajo de Jira para el desarrollo de software?
Un flujo de trabajo de Jira para el desarrollo de software es el conjunto de estados y transiciones que sigue una historia, un bug o una tarea desde el backlog hasta el lanzamiento, por ejemplo Backlog, In Progress, In Review, In QA y Done. Define qué estados existen, qué movimientos están permitidos, quién puede hacerlos y qué comprobaciones o automatizaciones se ejecutan en cada transición.
¿Cuál es el mejor flujo de trabajo de Jira para el desarrollo de software?
Para la mayoría de los equipos de producto, el mejor flujo de trabajo de Jira es Backlog, Selected for Development, In Progress, In Review, In QA y Done. Muestra por separado la programación, la revisión y las pruebas, se limita a seis estados y permite movimientos hacia atrás para el retrabajo. Los equipos pequeños sin QA pueden prescindir de In QA; los equipos Kanban suelen añadir Ready to Release.
¿Qué diferencia hay entre un flujo de trabajo de Jira y un tablero?
El flujo de trabajo define los estados que puede tener una incidencia y las transiciones permitidas entre ellos. El tablero es una vista visual que asigna esos estados a columnas y filtra las incidencias. Un mismo flujo de trabajo puede alimentar varios tableros, y una columna del tablero puede contener más de un estado.
¿Cuántos estados debe tener un flujo de trabajo de Jira?
Un equipo típico de desarrollo de software necesita entre 5 y 7 estados. Con menos, suelen quedar ocultas la revisión de código o las pruebas; con más, suele haber estados que describen personas o situaciones secundarias, que se gestionan mejor con responsables, marcas (flags) o etiquetas.
¿Puede Jira mover incidencias automáticamente desde GitHub o GitLab?
Sí. Con la integración de GitHub o GitLab conectada, Jira Automation puede reaccionar a eventos como la creación de una rama, la creación de un pull request, la fusión de un pull request, el estado de la build o un despliegue correcto, y hacer la transición de la incidencia, asignar un responsable o añadir un comentario. Incluya la clave de la incidencia en los nombres de las ramas, en los commits y en los títulos de los pull requests para que los eventos queden vinculados.
¿Con qué frecuencia conviene cambiar un flujo de trabajo de Jira?
Revise el flujo de trabajo cada trimestre y cámbielo solo cuando los datos o el feedback del equipo muestren un problema real, como un cuello de botella persistente o un estado que nadie utiliza. Los cambios frecuentes rompen los informes históricos y confunden a los equipos, así que agrupe los cambios y anúncielos antes de aplicarlos.
Publicado el 30 de octubre de 2026. Fuentes: Atlassian Support, working with workflows (en inglés); Atlassian Support, smart commits (en inglés); Atlassian, Jira Automation (en inglés); Atlassian, State of Developer Experience Report 2024 (en inglés). Los patrones de flujo de trabajo reflejan la práctica de entrega de YuSMP Group y son recomendaciones, no valores predeterminados de Atlassian.