Ciclos frente a sprints: qué cambia de verdad y cuál debería usar un equipo pequeño
Ciclos y sprints son bloques de tiempo fijos para trabajo planificado. Los ciclos quitan la ceremonia de Scrum.
En esta página
Un sprint y un ciclo son, en esencia, lo mismo: un bloque de tiempo fijo y corto en el que un equipo se compromete con un conjunto de trabajo elegido. La diferencia está en lo que los rodea. El sprint viene de Scrum y arrastra sus eventos, sus roles y el hábito de estimar en puntos. El ciclo, término que Linear popularizó, conserva el bloque de tiempo y descarta casi todo lo demás: el trabajo inacabado pasa al siguiente automáticamente, los periodos de enfriamiento están integrados, y la velocidad es opcional o no existe.
Si alguna vez has discutido si llamar a la cosa sprint o ciclo, esa discusión suele ser sobre ceremonia, no sobre el calendario. Este artículo explica de dónde vienen ambos términos, qué hace cada herramienta cuando se acaba el tiempo y cómo zanjamos la cuestión en nuestro propio equipo.
De dónde vienen los sprints
El sprint es un concepto de Scrum. La Guía de Scrum define los sprints como eventos de duración fija de un mes o menos, dice que un nuevo sprint empieza inmediatamente después de que termine el anterior, y da a cada sprint un único objetivo, el Sprint Goal. Alrededor del bloque de tiempo, Scrum coloca cuatro eventos: la planificación, el scrum diario, la revisión y la retrospectiva.
Nada de eso es opcional en Scrum tal como está escrito. La Guía también deja claro que las prácticas de previsión como burn-downs, burn-ups y flujos acumulados son útiles pero no sustituyen al empirismo; son instrumentos, no el método.
Jira es la herramienta donde la mayoría conoce los sprints. El consejo de Atlassian para equipos nuevos es un sprint fijo de dos semanas. Cuando pulsas "Completar sprint" en Jira con trabajo todavía abierto, eliges adónde va: al backlog, a cualquier sprint futuro ya creado, o a un sprint nuevo creado en el momento. La documentación de Jira describe esas tres opciones; la decisión es tuya cada vez.
De dónde vienen los ciclos
"Ciclo" como término de producto se extendió gracias a Linear, que eligió la palabra para señalar una versión más ligera de la misma idea. La documentación de ciclos de Linear describe la forma: el equipo elige una duración, de una a ocho semanas, y un día de inicio, y los ciclos se repiten con ese calendario. El equipo puede añadir un enfriamiento tras cada ciclo, un hueco para deuda técnica y planificación, y no se pueden asignar issues a un enfriamiento.
El comportamiento al final del ciclo es la mayor diferencia práctica con un sprint. En Linear, los issues abiertos pasan al siguiente ciclo automáticamente, y no hay forma de mantener issues inacabados en un ciclo cerrado. Donde Jira te pregunta adónde debe ir el trabajo inacabado, Linear ya lo ha movido. Linear también ofrece añadir automáticamente al ciclo actual los issues empezados, para que el trabajo iniciado fuera del plan se registre en lugar de perderse.
La planificación de capacidad existe, pero es discreta. Para un ciclo que no ha empezado, Linear estima la capacidad a partir del número de issues o de puntos de estimación completados en los tres ciclos anteriores. Puedes usar puntos si quieres; muchos equipos cuentan issues. Linear permite crear hasta quince ciclos futuros.
Ciclos frente a sprints: la comparación
La tabla compara el concepto tal como lo define Scrum, como lo implementa Jira, y como Linear y Atrix implementan los ciclos, a octubre de 2026.
| Sprint de Scrum | Sprint de Jira | Ciclo de Linear | Ciclo de Atrix | |
|---|---|---|---|---|
| Duración | Un mes o menos, fija | Cualquiera; se recomiendan dos semanas | De 1 a 8 semanas, fija por equipo | De 1 a 4 semanas, con objetivo |
| Objetivo | Obligatorio (Sprint Goal) | Campo opcional | Opcional | Se fija al crear el ciclo |
| Trabajo inacabado al final | Vuelve al backlog de producto para replanificar | Tú eliges: backlog, un sprint futuro o uno nuevo | Pasa al siguiente ciclo automáticamente | Pasa al siguiente ciclo o vuelve al backlog |
| Hueco entre bloques | Ninguno; el siguiente sprint empieza de inmediato | Ninguno integrado | Enfriamiento opcional; sin issues asignables | Ninguno integrado |
| Estimación | No prescrita | Puntos de historia habituales | Puntos de estimación opcionales | Ninguna; sin puntos de historia |
| Velocidad | No es un término de Scrum | Gráfico de velocidad | Capacidad según los tres últimos ciclos | No se mide; el burndown cuenta issues |
| Ceremonia | Planificación, scrum diario, revisión, retrospectiva | La que añada el equipo | La que añada el equipo | La que añada el equipo |
Lee una fila de lado a lado y el patrón es claro. Scrum define el método; Jira te da los campos para aplicarlo y te deja las decisiones; las herramientas basadas en ciclos toman las decisiones por ti y quitan los campos sobre los que podrías discutir.
Las tres diferencias que importan en el día a día
Qué pasa con el trabajo inacabado. En una herramienta de sprints, cerrar el bloque es una pequeña ceremonia con una decisión adjunta. En una de ciclos, es una fecha que pasa. El arrastre automático significa que nada se pierde por accidente, y significa que un equipo que planifica de más verá los mismos issues pasar de ciclo en ciclo tres veces seguidas. Esa visibilidad es el objetivo. Un ciclo que arrastra siempre el mismo trabajo es un problema de planificación, no de herramienta.
Si estimas o no. Los puntos de historia existen para prever cuánto puede asumir un equipo. Las herramientas de ciclos lo tratan como opcional, y algunas, incluida Atrix, no ofrecen puntos. Contar issues es más tosco pero más difícil de manipular, y para un equipo de cinco suele bastar. La contrapartida es honesta: si necesitas decirle a un cliente cuántas semanas llevará un alcance, puntos y velocidad te dan un número defendible; el recuento de issues te da uno aproximado.
Cuánta ceremonia va unida. Un sprint implica cuatro reuniones. Un ciclo no implica ninguna. La mayoría de equipos pequeños que usan ciclos hacen igualmente una planificación corta y algún tipo de revisión, pero lo eligen, y pueden saltarse la retrospectiva en una quincena tranquila sin sentir que han roto el método.
Enfriamientos y la cuestión de la cadencia
El "un nuevo sprint empieza de inmediato" de Scrum es deliberado: mantiene el ritmo estable y evita que los huecos entre sprints se coman una semana. El enfriamiento de Linear es la opción contraria: una pausa integrada en la que no se pueden asignar issues, pensada para deuda y planificación.
Por nuestra experiencia, el enfriamiento funciona cuando es corto y está protegido. Una semana tras un ciclo de seis da margen para arreglar lo que molestaba y planificar bien el siguiente bloque. Un enfriamiento que se convierte en "la semana en que nadie sabe qué hacer" es peor que ninguno. Si tu equipo son dos o tres personas, probablemente no lo necesitas; el final de un ciclo y el principio del siguiente pueden ser la misma tarde.
Qué usamos nosotros, y por qué
Usamos ciclos de dos semanas en Atrix, nuestro propio espacio de trabajo, para el trabajo de producto, y elegimos ciclos en lugar de sprints por una razón que no tiene nada que ver con el vocabulario. Con cuatro a seis personas por producto, el tiempo que dedicábamos a puntos y velocidad no mejoraba nuestras previsiones. Contar issues, con un objetivo por ciclo y un burndown de issues abiertos, nos decía lo que necesitábamos saber: ¿vamos a cumplir el objetivo o no?
Lo que Atrix te da, dicho sin rodeos: ciclos de una a cuatro semanas por producto, cada uno con un objetivo; planificas issues del backlog en un ciclo; el burndown cuenta issues abiertos; al completar un ciclo, lo inacabado pasa al siguiente o vuelve al backlog. Las etiquetas de colores y los hitos acompañan. Lo que no te da: puntos de historia, gráficos de velocidad ni un ajuste de enfriamiento. Si tu proceso depende de alguno de ellos, Jira o Linear encajan mejor, y la página de gestión de proyectos lo dice con claridad.
Cómo elegir para tu equipo
- Cuenta las personas y los clientes. De dos a ocho personas construyendo un producto: con ciclos contados en issues basta. Un equipo que debe dar fechas de entrega a clientes a partir de su rendimiento histórico: sprints con puntos, o ciclos con puntos de estimación en una herramienta que los tenga.
- Elige una duración y mantenla. Dos semanas es el valor habitual por algo; una semana va bien para un equipo que publica a diario, cuatro para trabajo con mucha investigación. Cambiar la duración en cada ciclo destruye la comparación entre ellos.
- Escribe un objetivo. Lo llame como lo llame la herramienta, un ciclo con una frase de intención es más fácil de planificar y de juzgar que una lista de issues.
- Decide la regla de arrastre una vez. Arrastre automático o decisión deliberada al cerrar. Ambas funcionan. Cambiar de idea cada vez es lo que hace que el trabajo desaparezca.
- Conserva la revisión, elimina lo que no uses. Un vistazo de quince minutos a lo publicado merece la pena incluso en el proceso más ligero. Una retrospectiva en cada ciclo solo merece la pena si cambia algo.
Si quieres una plantilla para empezar, la plantilla de planificación de sprint cubre un objetivo, la capacidad en issues y la lista de arrastre, y sirve para cualquiera de las dos palabras.
Preguntas frecuentes
¿Un ciclo es lo mismo que un sprint?
Ambos son bloques de tiempo fijos para trabajo planificado, así que en el uso diario son intercambiables. La diferencia está en lo que llevan adjunto: el sprint arrastra los eventos de Scrum y normalmente puntos y velocidad; el ciclo, en herramientas como Linear y Atrix, conserva el bloque de tiempo, arrastra lo inacabado automáticamente y trata la estimación como opcional.
¿Por qué Linear los llamó ciclos en lugar de sprints?
Linear usa la palabra para marcar una versión más ligera: duración fija, arrastre automático, enfriamientos opcionales y sin obligación de estimar. El término aleja la práctica de la ceremonia completa de Scrum sin cambiar la idea de fondo de trabajar en periodos cortos y fijos.
¿Qué pasa con los issues inacabados al final de un ciclo?
En Linear, los issues abiertos pasan al siguiente ciclo automáticamente; los inacabados no pueden quedarse en un ciclo cerrado. En Atrix, el trabajo inacabado pasa al siguiente ciclo o vuelve al backlog al completar el ciclo. En Jira, al completarlo eliges entre el backlog, un sprint futuro o uno nuevo.
¿Qué es un enfriamiento en la planificación por ciclos?
Un enfriamiento es un hueco opcional tras un ciclo, usado para deuda técnica, corrección de errores y planificación del siguiente. En Linear no se pueden asignar issues a un enfriamiento. Scrum no tiene equivalente; la Guía dice que un nuevo sprint empieza inmediatamente después del anterior.
¿Los ciclos usan puntos de historia o velocidad?
No necesariamente. Linear admite puntos de estimación opcionales y deriva la capacidad de los tres últimos ciclos completados, por issues o por puntos. Atrix no usa ni puntos ni velocidad; su burndown cuenta issues abiertos. Jira ofrece ambos de serie.
¿Cuánto debe durar un ciclo o un sprint?
La Guía de Scrum limita los sprints a un mes. Atlassian recomienda dos semanas para equipos nuevos. Linear permite de una a ocho semanas y Atrix de una a cuatro. Dos semanas es la elección más común en equipos de producto pequeños; lo importante es fijar la duración y mantenerla.
Siguiente paso
Lee la entrada de sprint en el glosario para la definición de Scrum y sus eventos, y luego monta un primer ciclo con la plantilla de planificación de sprint. Si quieres ciclos con un objetivo y un burndown por recuento de issues y nada más, eso es lo que hace la gestión de proyectos en Atrix.