# Kanban, Scrum o Scrumban: cómo elegir para tu equipo > Tres formas de organizar el trabajo de un equipo: un tablero continuo, sprints fijos o una mezcla. En qué se diferencian, cómo elegir y cómo lo admite Prior. Source: https://priortasks.com/es/guides/kanban-scrum-or-scrumban/ Last updated: 2026-11-05 Kanban, Scrum y Scrumban son tres formas de organizar el trabajo de un equipo. Kanban mueve el trabajo por un tablero, un elemento cada vez. Scrum trabaja en rondas fijas llamadas sprints. Scrumban toma partes de ambos. La adecuada depende de cómo llega tu trabajo y de cuánto puedes planificar. ## De dónde vienen **Kanban** viene de Toyota. Taiichi Ohno usaba tarjetas, llamadas *kanban* en japonés (una señal o tarjeta de aviso), para indicar a cada paso de una línea de producción cuándo fabricar más. El trabajo se extraía cuando había sitio para él, en lugar de empujarse. David J. Anderson adaptó la idea al software y al trabajo del conocimiento en *Kanban: Successful Evolutionary Change for Your Technology Business* (2010). Dos de sus prácticas básicas son visualizar el trabajo en un tablero y limitar cuánto se hace a la vez. **Scrum** lo describieron por escrito Ken Schwaber y Jeff Sutherland. La [Scrum Guide](https://scrumguides.org/scrum-guide.html) actual está fechada en noviembre de 2020. Un equipo Scrum tiene un Product Owner, un Scrum Master y Developers. El trabajo ocurre en sprints de un mes o menos. Cada sprint contiene la Planificación del Sprint, el Scrum Diario, la Revisión del Sprint y la Retrospectiva del Sprint. El equipo se compromete con un Objetivo del Sprint, y los Developers que harán el trabajo dimensionan los elementos. **Scrumban** lo describió Corey Ladas en su libro *Scrumban: Essays on Kanban Systems for Lean Software Development*. No tiene una única definición. Una versión habitual es un tablero con límites al trabajo en curso más algunas costumbres de Scrum, como una revisión periódica. Scrum.org también publica una [Kanban Guide for Scrum Teams](https://www.scrum.org/resources/kanban-guide-scrum-teams) para equipos que quieren llevar prácticas de flujo a Scrum. ## En qué se diferencian | | Kanban | Scrum | Scrumban | | --- | --- | --- | --- | | Ritmo | Continuo | Sprints fijos | Tablero más una revisión periódica | | Planificación | Cuando hay sitio | Al empezar un sprint | A menudo, cuando el tablero se vacía | | Cambiar a mitad | En cualquier momento | Limitado por el Objetivo del Sprint | Normalmente flexible | | Roles | Ninguno obligatorio | Product Owner, Scrum Master, Developers | Lo decide el equipo | | Estimaciones | Opcionales | Habituales, a menudo en story points | Opcionales | | Regla clave | Limitar el trabajo en curso | Comprometerse con un Objetivo del Sprint | Ambas | Los límites al trabajo en curso importan más de lo que parece. La ley de Little, de la teoría de colas, dice que en un proceso estable el tiempo medio que un elemento pasa en curso es igual al número medio de elementos en curso dividido por la velocidad a la que terminan. Si tu producción se mantiene y empiezas más elementos, cada uno tarda más. ## Cómo elegir Hazte tres preguntas. 1. **¿Cómo llega el trabajo?** Si es impredecible (peticiones de soporte, errores, encargos urgentes), encaja un tablero continuo. Si puedes planificar unas semanas por adelantado, encajan los sprints. 2. **¿Puede el equipo comprometerse a un objetivo durante un periodo?** Si alguien puede cambiar las prioridades cada día, es difícil proteger un sprint. Elige Kanban. 3. **¿Quieres una pausa regular para mirar atrás?** Scrum la incluye. En Kanban la añades tú. Algunos ejemplos. Un equipo de soporte que responde peticiones: Kanban. Un equipo de producto que entrega un conjunto de funciones cada dos semanas: Scrum. Un equipo pequeño que construye funciones y además atiende un flujo de errores: Scrumban. Una persona con una lista de proyectos: Kanban, o una lista sencilla. Cambiar es posible. Los equipos suelen empezar con un tablero, ven qué se atasca y añaden sprints más adelante, cuando la planificación empieza a importar. ## Errores que conviene evitar - **Un tablero sin límites.** Sin un límite al trabajo en curso, un tablero Kanban es una lista de tareas en columnas. - **Sprints sin objetivo.** Un sprint que es solo un cajón de tareas pierde el sentido de la ronda. - **Ritos por el rito.** Si una reunión nunca cambia una decisión, acórtala o elimínala. - **Planning poker para todo.** Estima lo que necesitas para planificar. - **Usar la velocidad o los gráficos de avance para juzgar a personas.** Son para la planificación del propio equipo. - **Cambiar de método a mitad de sprint.** Espera a un corte natural. ## Cuándo no son la herramienta adecuada - **Para una sola persona.** Una lista con una siguiente acción clara basta. - **Cuando el orden lo fijan las dependencias.** Un plan de obra o una lista de lanzamiento necesita una línea de tiempo, no un tablero. - **Cuando el trabajo es un único entregable grande.** Una tesis no es un flujo de elementos. - **Cuando nadie es dueño de las prioridades.** Scrum necesita a alguien que decida qué va primero. ## En Prior Prior admite los tres a través del **Tipo de proyecto** de un proyecto. Elígelo al crear o editar el proyecto. | Tipo | Lo que obtienes | Plan | | --- | --- | --- | | Estándar | Tareas y notas con estados y prioridades | Gratis | | Ágil · Kanban | Una lista de pendientes y un tablero donde el trabajo fluye por columnas | Gratis | | Ágil · Scrum | Sprints, story points y Planning Poker para el equipo | Pro | | Ágil · Scrumban | Un tablero continuo con story points y Planning Poker | Pro | > [!pro] Scrum y Scrumban necesitan Pro en el plan del propietario > Sin Pro, un proyecto Scrum o Scrumban funciona como un proyecto Kanban. Sus puntos, sus sprints y sus ajustes siguen guardados y vuelven cuando el propietario tiene Pro. Las personas que invitas no necesitan Pro. Mira [Planes y precios](https://priortasks.com/es/docs/account/plans-and-pricing/). - **El tablero.** Los proyectos ágiles tienen una pestaña **Tablero** junto a **Tareas**, **Resumen**, **Notas** y **Actividad**. Las columnas siguen los estados del proyecto, y cada una muestra cuántas tarjetas tiene. Arrastra una tarjeta a otra columna, o abre su menú y elige **Mover a** una columna. En el móvil, las columnas son píldoras encima del tablero. - **Kanban.** El tablero es el centro. Prior no aplica límites al trabajo en curso, así que mantén tu propio límite y vigila el contador de la parte superior de cada columna. **Todas las tareas** tiene también una vista **Kanban**, que puede agrupar por estado, prioridad, proyecto o fecha de vencimiento. - **Scrum.** Los **Ciclos** pasan a ser **Sprints**. Tienes un filtro de sprint en el tablero (**Sprint activo**, **Todas**, **Backlog**), progreso de puntos y velocidad en la pestaña **Sprints**, un gráfico de avance y la pestaña **Planning Poker**. - **Scrumban.** Mantiene los **Ciclos**, sin gráficos de avance, y añade story points. **Planning Poker** está disponible desde **Añadir una vista**. - **Cambiar de idea.** Cambiar el tipo conserva tus tareas. Los puntos, los sprints y la configuración anterior siguen guardados, así que volver atrás los restaura. Lee más en [Proyectos ágiles](https://priortasks.com/es/docs/agile/agile-projects/) y [Kanban, Scrum y Scrumban](https://priortasks.com/es/docs/agile/kanban-scrum-scrumban/). Para dimensionar, mira los [story points](https://priortasks.com/es/guides/story-points/) y el [planning poker](https://priortasks.com/es/guides/planning-poker/).