Dos preguntas distintas
A menudo se presenta Kanban y Scrum como dos platos del mismo menú. En la práctica parten de preguntas diferentes. Kanban pregunta: ¿dónde se atasca el trabajo? Scrum pregunta: ¿qué podemos entregar al final del ciclo? El resto de la comparación se deriva de ahí.
Kanban: vigilar el flujo
La Guía Kanban (edición de mayo de 2025) define Kanban como una estrategia para optimizar el flujo de valor a través de un proceso. Se apoya en tres prácticas: definir y visualizar el flujo de trabajo, gestionar activamente los elementos que lo recorren y mejorar el flujo. Sin iteración impuesta ni roles prescritos. Una sola exigencia es realmente firme: controlar el número de elementos en curso, desde que se empiezan hasta que se terminan.
¿Por qué pesa tanto ese límite? Porque actúa directamente sobre el tiempo que tarda una tarea en cruzar el tablero. La ley de Little dice que, en un sistema estable, el número medio de elementos en curso es igual al rendimiento medio multiplicado por el tiempo medio que un elemento pasa en el sistema (Little, 2011).
Un ejemplo con números inventados para la ocasión. Un equipo de soporte termina unos 5 tickets al día y mantiene 20 abiertos de forma permanente: cada ticket tarda de media 4 días en salir (20 ÷ 5). Si limita los tickets en curso a 8 sin que baje su rendimiento, el plazo medio cae a 1,6 días (8 ÷ 5). Nada se ha acelerado: simplemente se ha dejado de empezar todo a la vez.
Scrum: mantener un ritmo
La Guía de Scrum 2020 de Ken Schwaber y Jeff Sutherland describe Scrum como un marco ligero que ayuda a personas, equipos y organizaciones a generar valor mediante soluciones adaptativas a problemas complejos. Es preciso solo en pocos puntos: Sprints de un mes como máximo, un equipo de diez personas o menos, tres responsabilidades (Developers, Product Owner, Scrum Master), cinco eventos incluido el propio Sprint y tres artefactos (Product Backlog, Sprint Backlog, Incremento). Cada Sprint persigue un único objetivo, el Sprint Goal. Los detalles están en nuestro artículo sobre el método Scrum.
Qué cambia en la práctica
| Criterio | Kanban | Scrum |
|---|---|---|
| Pregunta de partida | ¿Dónde se estanca el trabajo? | ¿Qué se entrega al final del Sprint? |
| Lo que se acota | El número de elementos en curso | La duración del Sprint (un mes como máximo) |
| Roles obligatorios | Ninguno | Product Owner, Scrum Master, Developers |
| Cambiar de opinión a mitad de camino | Posible en cualquier momento, dentro del límite de trabajo en curso | El backlog se reordena; solo el Product Owner puede cancelar un Sprint |
| Medidas habituales | Tiempo de ciclo, rendimiento | Sprint Goal cumplido o no (la velocidad es una práctica extendida, pero la Guía no la menciona) |
Cómo elegir sin perderse
- El trabajo llega de forma continua, en piezas pequeñas y sin fecha común (soporte, contenido, contratación): Kanban encaja mejor, porque no hay un entregable colectivo que fijar en un calendario.
- El equipo construye un producto o una campaña y quiere un punto de control regular con las partes interesadas: Scrum aporta ese ritmo, siempre que se celebren sus eventos.
- Kanban sin límite de trabajo en curso se convierte en una lista de tareas más presentable. Scrum sin una retrospectiva que cambie algo se convierte en una sucesión de reuniones.
Muchos equipos mezclan ambos. Para un panorama de lo que la literatura ha recogido sobre el uso de Kanban en software, puede leerse la revisión sistemática de Ahmad, Markkula y Oivo (2013).
Fuentes
- Coleman, J., Vacanti, D., et al. (2025). The Kanban Guide (mayo de 2025). kanbanguides.org
- Schwaber, K., & Sutherland, J. (2020). The 2020 Scrum Guide. scrumguides.org
- Little, J. D. C. (2011). OR Forum: Little's Law as Viewed on Its 50th Anniversary. Operations Research, 59(3), 536-549. doi:10.1287/opre.1110.0940
- Ahmad, M. O., Markkula, J., & Oivo, M. (2013). Kanban in software development: A systematic literature review. 39th EUROMICRO Conference on Software Engineering and Advanced Applications, 9-16. doi:10.1109/SEAA.2013.28