METODOLOGÍA

Scrum

Un marco ágil que organiza el trabajo en sprints de duración fija, con roles, eventos y artefactos definidos para mantener a un equipo entregando e inspeccionando en un ciclo cerrado.

Última revisión: 2026-06-02 porKevin Riedl wiki ↗

Scrum tiene tres roles, tres artefactos y un puñado de eventos. El Product Owner decide qué se construye y en qué orden. El Scrum Master elimina los bloqueos y protege el proceso. Los desarrolladores lo construyen. Los artefactos son el product backlog (todo lo que podría construirse), el sprint backlog (a lo que se compromete este sprint) y el incremento (lo que realmente se entrega). Los eventos son la planificación del sprint, el daily standup, la revisión del sprint y la retrospectiva.

Donde Scrum ayuda de verdad: en equipos que luchan con el foco y la visibilidad. El sprint fijo obliga a un compromiso real, la revisión obliga a una demo real y la retro obliga al equipo a mirar su propio proceso en lugar de ignorarlo. Para un equipo que nunca ha entregado a un ritmo, Scrum es un andamiaje útil.

Donde se convierte en teatro: cuando los eventos sobreviven pero la sustancia muere. Un standup que es un informe de estado para el manager. Una revisión sin software funcional que mostrar. Una retro que produce las mismas tres acciones cada quincena y no actúa sobre ninguna. Muchos equipos de “Scrum” ejecutan las ceremonias y no obtienen ningún valor. Si haces las reuniones pero no puedes demostrar un incremento funcional, no tienes Scrum, tienes un hábito de reuniones.

La visión honesta de Wavect: Scrum es un buen marco de inicio y una mala religión. Conserva las partes que crean retroalimentación y descarta las que crean sobrecarga. La mayoría de los equipos maduros derivan hacia algo más ligero, a menudo más cercano a Kanban, una vez que la disciplina se interioriza.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Un marco ágil que ejecuta el trabajo en sprints de duración fija con tres roles (Product Owner, Scrum Master, desarrolladores), tres artefactos (product backlog, sprint backlog, incremento) y cuatro eventos (planificación, standup, revisión, retro). El objetivo es un ciclo cerrado de construcción e inspección, no las reuniones en sí.
Scrum agrupa el trabajo en sprints fijos con un compromiso y una revisión en cada límite. Kanban funciona como un flujo continuo con límites de WIP y sin iteraciones fijas. Elige Scrum cuando un equipo necesita la estructura de un ritmo para construir disciplina de entrega. Elige Kanban cuando el trabajo llega de forma impredecible o el equipo es lo bastante maduro para gestionar el flujo sin el andamiaje.
Cuando las ceremonias se ejecutan pero no producen nada. Un standup que se volvió una reunión de estado, una revisión sin demo, una retro que no cambia nada. Si no puedes mostrar un incremento funcional al final de un sprint, el marco es teatro y deberías arreglar la sustancia, no añadir más proceso.