Scrum es el marco ágil más usado del mundo y también el más maltratado: hay más empresas que dicen hacer Scrum que empresas que lo hacen. Esta guía explica las piezas del marco y, sobre todo, para qué sirve cada una, porque los rituales vaciados de propósito son exactamente lo que convierte Scrum en teatro.
La idea central
Scrum organiza el trabajo en sprints: ciclos de duración fija, normalmente de dos semanas, que terminan siempre con un incremento de producto utilizable. No «avance», no «un 80% de la pantalla»: algo que funciona y se puede enseñar.
Esa obligación de entregar algo real cada pocas semanas es el motor de todo lo demás. Obliga a trocear el trabajo, saca los problemas a la luz pronto y sustituye las discusiones de opiniones por discusiones sobre algo que se puede tocar.
Los tres roles
Product Owner. El dueño del «qué» y del «para qué». Mantiene el backlog ordenado por valor y decide qué se aborda primero. Es un rol de decisión, no un secretario de peticiones: un Product Owner que solo transcribe lo que piden los stakeholders no está ejerciendo.
Scrum Master. El guardián del método. Quita impedimentos, protege al equipo de interrupciones y evita que el marco se degrade. No es el jefe del equipo ni un gestor de proyectos con otro nombre; es más parecido a un entrenador.
Developers. Quienes construyen el incremento, sea código, diseño o contenido. Se organizan solos: deciden cómo repartir y abordar el trabajo del sprint. Esa autonomía no es un privilegio, es la contrapartida de comprometerse con un objetivo.
Los cinco eventos
El sprint. El contenedor de todo, con duración fija e innegociable. Empezar a estirar sprints «para terminar lo que falta» es la primera señal de que algo va mal.
Sprint planning. Al arrancar el ciclo, el equipo selecciona del backlog lo que cabe en el sprint y define un objetivo. La pregunta clave no es «¿cuántas tareas entran?» sino «¿qué queremos haber logrado dentro de dos semanas?».
Daily scrum. Quince minutos al día, de pie si hace falta, para sincronizar: qué hice, qué haré, qué me bloquea. Es del equipo y para el equipo. Cuando degenera en reporte al jefe, pierde su función y empieza a sobrar.
Sprint review. Al final del ciclo se muestra el incremento a los interesados y se recoge feedback de verdad. Es la reunión que convierte Scrum en un sistema que aprende; sin stakeholders presentes es un trámite.
Retrospectiva. El equipo, a solas, examina cómo trabajó y elige una o dos mejoras concretas para el siguiente sprint. Es la práctica con mejor relación esfuerzo/beneficio de todo el marco, y la primera que se sacrifica cuando hay prisa. Mal síntoma. Tienes plantilla descargable aquí.
Los tres artefactos
Product backlog: la lista única y priorizada de todo lo pendiente. Sprint backlog: lo seleccionado para el ciclo actual, con su plan. Incremento: el resultado utilizable que cada sprint añade sobre el anterior.
A los tres los acompaña una pieza poco glamurosa y crucial: la definition of done. Qué significa exactamente «terminado» —¿probado?, ¿documentado?, ¿desplegado?—. La mitad de las broncas en equipos Scrum nacen de no haberla escrito.
Por qué Scrum falla en tantas empresas
Casi siempre por las mismas vías: sprints interrumpidos constantemente con urgencias (el sprint deja de significar compromiso), Product Owner sin poder real de decisión, dailies convertidas en tribunal, y retrospectivas suprimidas o sin consecuencias.
El patrón de fondo: adoptar la liturgia sin aceptar el cambio de poder que implica. Scrum reparte decisiones que antes tenía un jefe. Si la organización no está dispuesta a repartirlas, celebrará todas las ceremonias y no obtendrá ninguno de los beneficios.
Para empezar bien
Si tu equipo arranca con Scrum: sprints de dos semanas, respeto estricto a los límites de tiempo de cada evento, una definition of done escrita y una sola mejora por retrospectiva, con responsable. La disciplina del marco, sostenida tres o cuatro sprints, es lo que hace aparecer los resultados.
Preguntas frecuentes
¿Cuánto dura un sprint en Scrum?
Entre una y cuatro semanas, con dos como duración más común. Lo innegociable no es la cifra sino la fijeza: todos los sprints del equipo duran lo mismo, y no se estiran para «terminar lo que falta».
¿Scrum solo sirve para software?
No. Funciona en cualquier trabajo que se pueda entregar por incrementos: marketing, diseño, contenidos, hardware. Donde encaja mal es en trabajo de flujo continuo (soporte, incidencias), donde Kanban es mejor opción.
¿El Scrum Master es el jefe de proyecto?
No. No asigna tareas ni responde del resultado del producto: facilita el proceso y quita impedimentos. En organizaciones que vienen de estructuras clásicas, esta confusión es la primera causa de un Scrum disfuncional.