Guía Agile · Prácticas ágiles
¿Qué es un Sprint en Agile? Duración, eventos y ejemplos
Un sprint en Agile es un periodo corto y fijo, de un mes o menos y casi siempre de dos semanas, en el que un equipo convierte un conjunto de elementos del backlog en un resultado utilizable. Los sprints dan a los equipos ágiles un ritmo constante de planificación, construcción, revisión y mejora. Esta guía explica cómo funcionan los sprints, cuánto deben durar, qué ocurre dentro de ellos y cómo es un sprint real de dos semanas día a día.
Puntos clave
- Un sprint es un bloque de tiempo fijo de un mes o menos con un único Objetivo del Sprint; dos semanas es la duración más habitual.
- Cada sprint incluye la Sprint Planning, las Daily Scrums, una Sprint Review y una Sprint Retrospective, y termina con un Incremento utilizable.
- El Objetivo del Sprint es el compromiso. El alcance puede renegociarse, pero se evitan los cambios que pongan en peligro el objetivo.
- Los sprints nunca se prolongan. El trabajo sin terminar vuelve al Product Backlog y el siguiente sprint comienza de inmediato.
- Solo el Product Owner puede cancelar un sprint, y únicamente si el Objetivo del Sprint queda obsoleto.
- La mayoría de los problemas en los sprints se deben a comprometerse en exceso, a objetivos vagos y a empezar demasiado trabajo a la vez.
¿Qué es un sprint en Agile?
A sprint es un periodo de duración fija de un mes o menos en el que un equipo ágil trabaja hacia un único Objetivo del Sprint y produce al menos un Incremento utilizable del producto. Los sprints se suceden sin interrupción, y toda la planificación, coordinación, revisión y mejora del producto tiene lugar dentro de ellos.
El término procede de Scrum, el marco ágil más utilizado. La Guía de Scrum (edición de 2020, que sigue siendo la versión oficial vigente) describe los sprints como el latido de Scrum, donde las ideas se convierten en valor. Otros métodos ágiles utilizan la palabra iteración para la misma idea, y muchos equipos que no siguen Scrum de forma estricta siguen diciendo «sprint».
Sea cual sea el nombre, un sprint tiene cinco rasgos que lo definen:
- Duración fija. La duración se fija de antemano y se mantiene igual de un sprint a otro, para que el equipo aprenda su ritmo.
- Un objetivo. Cada sprint tiene un Objetivo del Sprint: un único objetivo que explica por qué merece la pena hacer el sprint.
- Un resultado utilizable. Al final, el equipo tiene un Incremento que cumple la Definición de Terminado, aunque todavía no se haya publicado.
- Uno tras otro. Un nuevo sprint comienza inmediatamente después de que termine el anterior.
- Todo ocurre dentro. La planificación, la coordinación diaria, el refinamiento, la revisión y la retrospectiva tienen lugar dentro del sprint, no antes ni después.
Los ciclos cortos y fijos son lo que hace que Agile sea empírico: cada pocas semanas, el equipo y sus interesados examinan resultados reales que funcionan y deciden qué hacer a continuación.
Sprint vs iteración vs Scrum
Estos términos suelen confundirse. La tabla muestra cómo se relacionan.
| Término | Qué es | Dónde se utiliza |
|---|---|---|
| Sprint | Un bloque de tiempo fijo de un mes o menos que produce un Incremento utilizable | Scrum y, de forma más general, la mayoría de los equipos ágiles |
| Iteración | El nombre genérico de un ciclo de desarrollo repetido y con bloque de tiempo | XP, SAFe, DSDM/AgilePM y la literatura ágil en general |
| Scrum | El marco que define los sprints, los roles, los eventos y los artefactos | Equipos que siguen la Guía de Scrum |
| Lanzamiento | Entregar un Incremento a los usuarios; puede ocurrir varias veces por sprint o tras varios sprints | Todos los enfoques de entrega |
| Program Increment (PI) | Un intervalo de planificación más largo, normalmente de varias iteraciones, que se usa para alinear a muchos equipos | SAFe (Scaled Agile Framework) |
En resumen, un sprint es un tipo de iteración, y Scrum es el marco que da sus reglas al sprint. La idea que subyace a ambos es el desarrollo iterativo e incremental: construir el producto en pequeñas porciones y mejorarlo en cada ciclo.
¿Cuánto dura un sprint?
La Guía de Scrum establece una sola regla: un sprint dura un mes o menos. Dentro de ese límite, el equipo elige. En la práctica, la mayoría de los equipos hacen sprints de una a cuatro semanas, y dos semanas es con diferencia la opción más habitual, porque equilibra la rapidez de los comentarios con el esfuerzo de planificar y revisar.
| Duración | Funciona bien para | Precauciones |
|---|---|---|
| 1 semana | Productos que evolucionan rápido, start-ups en fase inicial, equipos que necesitan comentarios muy rápidos | Los eventos ocupan una mayor parte del tiempo; es difícil terminar elementos grandes |
| 2 semanas | La mayoría de los equipos; una buena opción por defecto cuando se empieza | Puede seguir ocultando una minicascada si los elementos son demasiado grandes |
| 3 semanas | Equipos con ciclos de prueba más largos o pasos de aprobación regulados | Menos habitual, por lo que es más difícil alinearse con otros equipos |
| 4 semanas / un mes | Trabajo complejo que necesita más tiempo para mostrar resultados; entornos estables | Comentarios más lentos, más riesgo de desviarse del objetivo, sesiones de planificación más largas |
Cómo elegir la duración del sprint
Elija la duración más corta en la que el equipo pueda entregar algo significativo y Terminado. Después, tenga en cuenta:
- La rapidez con que cambian las cosas. Cuanto más volátiles sean el mercado o los requisitos, más corto debe ser el sprint.
- Cuánto pueden esperar los comentarios. Si los interesados necesitan ver avances cada semana, un sprint de cuatro semanas es demasiado largo.
- El tamaño de los elementos. Si la mayoría de los elementos del backlog tardan más de unos pocos días, divídalos antes de alargar el sprint.
- Las restricciones de publicación y de pruebas. La integración, los controles de cumplimiento o los plazos de entrega del hardware pueden hacer poco prácticos los sprints muy cortos.
- La alineación. Los equipos que trabajan en el mismo producto suelen compartir la duración del sprint y la fecha de inicio.
Cambiar la duración del sprint
Mantenga la duración estable durante al menos varios sprints para que su velocidad y sus pronósticos tengan sentido. Cámbiela de forma deliberada en una retrospectiva, no a mitad del sprint, y nunca alargue un sprint concreto porque quede trabajo sin terminar. Para conocer las reglas específicas de Scrum, consulte nuestra guía sobre el ciclo del Sprint en Scrum.
Los componentes de un sprint
Tres elementos dan forma a un sprint: un objetivo, un plan y un resultado.
Objetivo del Sprint
El Objetivo del Sprint es el único objetivo del sprint. Se crea durante la Sprint Planning y es el compromiso que asumen los Developers. Un buen Objetivo del Sprint describe un resultado, no una lista de tickets, lo que deja al equipo margen para ajustar el trabajo detallado a medida que aprende.
- Débil: «Completar los tickets 412, 415, 419 y 420».
- Mejor: «Permitir que los clientes recurrentes paguen en un solo paso para comprobar si se reducen los carritos abandonados».
- Ejemplo ajeno al software: «Lanzar la página de destino de la campaña de primavera y los dos primeros correos electrónicos para que el equipo de ventas pueda empezar la prospección el lunes».
Sprint Backlog
El Sprint Backlog está formado por el Objetivo del Sprint, los elementos del Product Backlog seleccionados para el sprint y el plan de los Developers para entregarlos. Pertenece a los Developers, que lo actualizan a lo largo del sprint para que todos puedan ver el trabajo pendiente.
Incremento y Definición de Terminado
Un Incremento es un paso hacia el objetivo del producto que es utilizable y cumple la Definición de Terminado. El trabajo que no cumple la Definición de Terminado no forma parte del Incremento, por muy cerca que esté. En un sprint se pueden crear varios Incrementos y se pueden publicar en cualquier momento; la Sprint Review no es una puerta de publicación.
Los eventos dentro de un sprint
El sprint es un contenedor para otros cuatro eventos. Los bloques de tiempo que aparecen a continuación son los máximos que indica la Guía de Scrum para un sprint de un mes; en sprints más cortos, los eventos suelen ser más breves.
| Evento | Propósito | Quién participa | Bloque de tiempo máximo (sprint de un mes) |
|---|---|---|---|
| Sprint Planning | Acordar por qué el sprint es valioso (Objetivo del Sprint), qué se puede hacer y cómo | Todo el Scrum Team | 8 horas |
| Daily Scrum | Inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el plan para el día siguiente | Developers (otros pueden asistir) | 15 minutos, todos los días |
| Sprint Review | Mostrar el resultado a los interesados y adaptar el Product Backlog | Scrum Team e interesados clave | 4 horas |
| Sprint Retrospective | Mejorar la forma de trabajar del equipo: personas, procesos, herramientas, Definición de Terminado | Scrum Team | 3 horas |
Sprint Planning abre el sprint. El Product Owner explica qué objetivos son más importantes, los Developers seleccionan los elementos que creen que pueden terminar y, juntos, el equipo elabora el Objetivo del Sprint. A continuación, los Developers planifican cómo hacer el trabajo, a menudo dividiendo los elementos en tareas de un día o menos.
La Daily Scrum es una revisión de 15 minutos para los Developers. No es un informe de estado para un responsable. La pregunta importante es: ¿vamos bien encaminados hacia el Objetivo del Sprint y, si no, qué cambiamos hoy?
La Sprint Review es una sesión de trabajo, no una presentación de diapositivas. El equipo muestra lo que está Terminado, los interesados aportan comentarios y el grupo comenta qué hacer a continuación, lo que actualiza el Product Backlog.
La Sprint Retrospective cierra el sprint. El equipo elige un pequeño número de mejoras concretas, y las más importantes pueden añadirse al siguiente Sprint Backlog.
Refinamiento del backlog no es un evento, sino una actividad continua durante el sprint. El equipo aclara, divide y dimensiona los próximos elementos para que la siguiente Sprint Planning sea rápida.
Para ver agendas y consejos de facilitación de cada reunión, consulte nuestra guía sobre ceremonias de Scrum.
Quién hace qué en un sprint
Un Scrum Team tiene tres responsabilidades. Las tres son necesarias para que un sprint funcione.
| Rol | Principales responsabilidades durante un sprint |
|---|---|
| Product Owner | Ordena el Product Backlog, propone cómo el sprint puede aportar valor, responde a preguntas sobre los elementos, trabaja con los interesados en lo que viene a continuación y es la única persona que puede cancelar un sprint |
| Developers | Seleccionan el trabajo, crean el plan, construyen y prueban el Incremento, celebran la Daily Scrum, actualizan el Sprint Backlog y se exigen responsabilidades mutuamente |
| Scrum Master | Se asegura de que los eventos se celebren y respeten sus bloques de tiempo, elimina impedimentos y hace de coach del equipo y de la organización |
| Interesados | Participan en la Sprint Review, aportan comentarios y ayudan a decidir lo que viene a continuación |
Observe que nadie asigna tareas a los Developers; ellos mismos organizan el trabajo.
Cómo planificar y llevar a cabo un sprint, paso a paso
Esta es la secuencia que recomendamos a un equipo que realiza sus primeros sprints. Sigue la Guía de Scrum, con hábitos prácticos añadidos.
- Prepare el Product Backlog. Antes de planificar, asegúrese de que los elementos principales estén ordenados, sean claros y lo bastante pequeños como para terminarlos dentro del sprint. De esto se encarga el refinamiento del sprint anterior.
- Compruebe la capacidad. Anote las vacaciones, la formación y otros compromisos para saber cuánto tiempo tiene realmente el equipo. Nuestra guía de planificación de la capacidad en Agile explica cómo hacerlo.
- Acuerde el Objetivo del Sprint. En la Sprint Planning, el Product Owner propone el objetivo y el equipo le da forma en una frase clara.
- Seleccione el trabajo. Los Developers toman elementos de la parte superior del backlog hasta alcanzar una carga realista, usando como referencia la velocidad o el rendimiento recientes.
- Planifique el cómo. Divida los primeros días de trabajo en tareas y acuerde quién empieza qué. No es necesario planificar todas las tareas por adelantado.
- Trabaje en lotes pequeños. Termine los elementos antes de empezar otros nuevos. Cuando alguien está bloqueado, los demás ayudan; esto se denomina swarming.
- Inspeccione a diario. Use la Daily Scrum y un tablero Scrum visible para detectar pronto los riesgos para el Objetivo del Sprint.
- Refine el trabajo próximo. Dedique algo de tiempo en cada sprint a preparar el siguiente conjunto de elementos; ediciones anteriores de la Guía de Scrum indicaban que esto no suele ocupar más del 10 % de la capacidad del equipo, y muchos equipos lo siguen usando como regla general.
- Revise con los interesados. Muestre lo que está Terminado, recoja comentarios y actualice el Product Backlog.
- Mejore. Celebre la retrospectiva, elija una o dos acciones y llévelas al siguiente sprint, que comienza de inmediato.
Una plantilla de planificación del sprint lista para usar le ofrece un lugar para el Objetivo del Sprint, la capacidad, los elementos seleccionados y las tareas.
Ejemplo: un sprint de dos semanas, día a día
Así podría ser un sprint típico de dos semanas para un equipo de producto de seis personas que trabaja de lunes a viernes. Los horarios son orientativos; ajústelos a su propio calendario.
| Día | Qué ocurre |
|---|---|
| Día 1 (lun.) | Sprint Planning (unas 2–4 horas). Objetivo del Sprint acordado; elementos seleccionados; primeras tareas planificadas |
| Días 2–4 | Daily Scrum cada mañana. Los Developers construyen y prueban los primeros elementos y los terminan uno a uno |
| Día 5 (vie.) | Revisión a mitad del sprint en la Daily Scrum: ¿sigue siendo alcanzable el objetivo? Se renegocia el alcance con el Product Owner si es necesario |
| Días 6–7 | El trabajo continúa. Una sesión de refinamiento prepara los elementos para el siguiente sprint |
| Días 8–9 | Los elementos restantes se terminan e integran. No se empiezan nuevos elementos grandes |
| Día 10 (vie.) | Sprint Review (unas 1–2 horas) con los interesados y, después, Sprint Retrospective (unas 1–1,5 horas) |
| El lunes siguiente | El siguiente sprint comienza con la Sprint Planning |
Ejemplos de Objetivos del Sprint
- Producto de software: «Los nuevos usuarios pueden registrarse con un correo electrónico de trabajo e invitar a un compañero, para que podamos iniciar la beta de incorporación».
- Equipo de marketing: «Publicar la página de destino del webinar y el flujo de registro para abrir las inscripciones al evento de junio».
- Equipo de RR. HH.: «Probar la nueva lista de verificación de incorporación con las dos personas que se incorporan este mes».
- TI interna: «Migrar al equipo de finanzas a la nueva configuración de portátiles sin que pierda el acceso a las unidades compartidas».
¿Se puede cambiar, prolongar o cancelar un sprint?
La Guía de Scrum establece reglas claras para un sprint en curso:
- No se hacen cambios que pongan en peligro el Objetivo del Sprint. Se puede hablar del nuevo trabajo urgente, pero el equipo protege el objetivo.
- La calidad no disminuye. La Definición de Terminado no se relaja para cumplir una fecha.
- El alcance puede aclararse y renegociarse con el Product Owner a medida que el equipo aprende más. Los elementos pueden intercambiarse o descartarse siempre que el objetivo se mantenga.
- El Product Backlog se refina según sea necesario.
No se permite prolongar un sprint. El bloque de tiempo es fijo. El trabajo que no está Terminado vuelve al Product Backlog, donde el Product Owner lo reordena; no pasa automáticamente al siguiente sprint, y el trabajo parcial no cuenta para la velocidad.
Cancelar un sprint es posible, pero poco frecuente. Solo puede hacerlo el Product Owner, y únicamente si el Objetivo del Sprint queda obsoleto, por ejemplo porque la empresa cambia de rumbo o el mercado varía. Todo el trabajo Terminado se revisa y los elementos incompletos vuelven al Product Backlog.
Si los interesados siguen introduciendo trabajo nuevo en sprints en curso, trátelo como una forma de corrupción del alcance: canalice las solicitudes a través del Product Owner y del Product Backlog.
Cómo hacer el seguimiento del progreso durante un sprint
No necesita informes complejos para gestionar un sprint, pero sí ver si el objetivo va por buen camino.
- Tablero Scrum o Kanban. Columnas como Por hacer, En curso, Revisión y Terminado muestran el trabajo de un vistazo y hacen visibles los cuellos de botella.
- Gráfico burndown del sprint. Representa el trabajo restante cada día frente a una línea ideal. Una línea plana durante varios días es una señal de alerta temprana.
- Comprobación del Objetivo del Sprint. En cada Daily Scrum, pregunte si el objetivo sigue siendo alcanzable; esto importa más que cualquier gráfico.
- Velocidad o rendimiento (después del sprint). La cantidad de trabajo terminado por sprint, que se usa para planificar los sprints futuros. Consulte Gráficos de velocidad en Agile.
- Tasa de éxito del Objetivo del Sprint. A lo largo de varios sprints, la frecuencia con la que el equipo cumplió su objetivo es una medida útil de previsibilidad.
Mida lo que mida, utilícelo para ayudar al equipo a adaptarse, no para comparar equipos ni personas.
Beneficios de trabajar en sprints
- Comentarios rápidos. Los interesados ven resultados que funcionan cada pocas semanas, y no al final del proyecto.
- Foco. Un único objetivo y un horizonte corto reducen la multitarea y los cambios de contexto.
- Menor riesgo. Los problemas aparecen en el plazo de un sprint, cuando es más barato solucionarlos.
- Previsibilidad. Una cadencia constante facilita los pronósticos y la planificación de lanzamientos.
- Mejora integrada. La retrospectiva ofrece al equipo un tiempo regular y protegido para mejorar su forma de trabajar.
- Transparencia. Los objetivos, los backlogs y los tableros hacen visible el progreso para todos.
Errores comunes en los sprints y cómo corregirlos
| Error | Por qué perjudica | Solución |
|---|---|---|
| Comprometerse en exceso | El trabajo se desborda, la moral cae y los pronósticos pierden sentido | Planifique según la velocidad reciente y la capacidad real; comprométase con el objetivo, no con cada elemento |
| Sin un Objetivo del Sprint real | El sprint se convierte en una lista de tareas sin motivo para adaptarse | Redacte una frase basada en resultados en la Sprint Planning |
| Minicascada dentro del sprint | El análisis, la construcción y las pruebas se suceden, por lo que nada está Terminado hasta el último día | Divida los elementos para que cada uno pueda construirse y probarse en pocos días |
| Demasiados elementos en curso | Al final, todo está terminado al 90 % | Limite el trabajo en curso y termine antes de empezar |
| Prolongar el sprint | Rompe la cadencia y oculta el problema real | Devuelva el trabajo sin terminar al backlog y analice el motivo en la retrospectiva |
| Omitir la retrospectiva | Los mismos problemas se repiten sprint tras sprint | Hágala breve si es necesario, pero celébrela siempre y aplique al menos una mejora |
| Cambiar a menudo la duración del sprint | La velocidad y los pronósticos pierden su significado | Mantenga la duración estable y cámbiela solo de forma deliberada |
| Usar la Daily Scrum como reunión de estado | Los Developers informan a un responsable en lugar de planificar juntos | Céntrese en el Objetivo del Sprint y en el plan para las próximas 24 horas |
¿Todos los equipos ágiles usan sprints?
No. Los sprints pertenecen a Scrum y a métodos basados en iteraciones como XP y SAFe. Otros enfoques funcionan de forma diferente:
- Kanban utiliza un flujo continuo con límites al trabajo en curso en lugar de sprints fijos; la planificación y las publicaciones se producen cuando es necesario. Compárelos en Kanban vs Scrum.
- Scrumban combina ambos, a menudo manteniendo una cadencia de planificación mientras gestiona el trabajo como un flujo.
- Los design sprints son una idea distinta: un taller estructurado de unos cinco días (popularizado por Google Ventures) para explorar y probar un concepto de producto. Comparten el nombre, pero no las reglas de Scrum.
Para ver cómo se comparan estos enfoques, lea tipos de metodologías ágiles.
Plantillas y herramientas para sprints
Puede hacer sprints con notas adhesivas y una pizarra, pero las plantillas y el software facilitan compartir el trabajo, sobre todo en equipos remotos.
- Plantilla de planificación del sprint: Objetivo del Sprint, capacidad, elementos seleccionados, estimaciones y tareas.
- Plantilla de retrospectiva del sprint: qué salió bien, qué mejorar y acciones.
- Plantilla de Product Backlog: una lista ordenada de elementos listos para futuros sprints.
- Plantilla de historia de usuario: historias coherentes con criterios de aceptación y estimaciones.
- Plantilla de plan de proyecto ágil: lanzamientos, sprints e hitos en una sola vista.
Hoy en día, la mayoría de las herramientas de gestión de proyectos admiten sprints. Jira está diseñado en torno a tableros Scrum y Kanban para equipos de software, mientras que Wrike, nuestra herramienta mejor valorada en general, se adapta a equipos que hacen sprints junto con otros tipos de trabajo entre departamentos.
Plantillas gratuitas sobre este tema
Preguntas frecuentes
¿Qué es un sprint en términos sencillos?
Un sprint es un bloque de tiempo corto y fijo, normalmente de dos semanas, en el que un equipo acuerda un objetivo, realiza el trabajo para alcanzarlo, muestra el resultado y, después, mejora su forma de trabajar antes de que empiece el siguiente sprint.
¿Cuánto dura un sprint en Agile?
En Scrum, un sprint dura un mes o menos. La mayoría de los equipos utilizan de una a cuatro semanas, y dos semanas es la duración más habitual. La duración se mantiene igual de un sprint a otro.
¿Por qué la mayoría de los sprints duran dos semanas?
Dos semanas es tiempo suficiente para terminar un trabajo significativo y lo bastante corto para obtener comentarios frecuentes. También mantiene en un nivel razonable el esfuerzo de planificación y revisión. Es una convención, no una regla de la Guía de Scrum.
¿Cuál es la diferencia entre un sprint y una iteración?
Un sprint es el nombre que Scrum da a una iteración: un ciclo de desarrollo repetido y con bloque de tiempo. Otros métodos, como XP y SAFe, usan la palabra iteración para la misma idea.
¿Cuál es la diferencia entre Scrum y un sprint?
Scrum es el marco, con sus roles, eventos y artefactos. Un sprint es uno de los eventos de Scrum: el bloque de tiempo fijo que contiene todos los demás eventos y el trabajo.
¿Qué ocurre al final de un sprint?
El equipo celebra una Sprint Review para inspeccionar el Incremento con los interesados y actualizar el Product Backlog y, después, una Sprint Retrospective para mejorar su forma de trabajar. El siguiente sprint comienza inmediatamente.
¿Qué ocurre con el trabajo sin terminar al final de un sprint?
Vuelve al Product Backlog, donde el Product Owner lo reordena. No cuenta como Terminado ni para la velocidad, y no pasa automáticamente al siguiente sprint.
¿Se puede ampliar un sprint?
No. El sprint tiene un bloque de tiempo. Si el trabajo no está terminado, vuelve al Product Backlog y el siguiente sprint empieza según lo previsto. Analice la causa en la retrospectiva.
¿Quién puede cancelar un sprint?
Solo el Product Owner, y únicamente si el Objetivo del Sprint queda obsoleto. La cancelación es poco frecuente porque los sprints son cortos y, por lo general, el equipo puede adaptar el plan.
¿Hay una pausa entre sprints?
No. Según la Guía de Scrum, un nuevo sprint comienza inmediatamente después de que termine el anterior. Algunos equipos programan tiempo para la innovación o hackatones, pero en Scrum eso ocurre dentro de un sprint.
¿Qué es el sprint cero?
Un término informal para un periodo de preparación antes del primer sprint, que se usa para configurar herramientas, entornos y un backlog inicial. La Guía de Scrum no lo define, y muchos coaches recomiendan que sea muy breve o que se entregue algo utilizable incluso en el primer sprint.
¿Cuántas historias de usuario debe haber en un sprint?
No hay un número fijo. Varias historias pequeñas, cada una terminable en pocos días, suelen funcionar mejor que unas pocas grandes. Use como referencia la velocidad o el rendimiento recientes.
¿Quién decide qué entra en un sprint?
El Product Owner ordena el Product Backlog y propone el objetivo. Los Developers deciden cuánto pueden asumir y seleccionan los elementos. Todo el Scrum Team acuerda el Objetivo del Sprint.
¿Kanban usa sprints?
No. Kanban gestiona el trabajo como un flujo continuo con límites al trabajo en curso en lugar de bloques de tiempo fijos, aunque algunos equipos Kanban celebran reuniones periódicas de planificación o revisión con una cadencia.