Qué es Scrum, sin certificaciones

Scrum es un framework para gestionar trabajo complejo en iteraciones cortas llamadas sprints. Cada sprint tiene una duración fija (generalmente 2 semanas), un objetivo claro y una lista de tareas que el equipo se compromete a completar. Al final del sprint, se entrega algo que funciona — no necesariamente completo, pero usable.

La diferencia clave con Waterfall (cascada) es que Scrum permite cambiar el alcance entre sprints según lo que se aprendió. Si descubrís que una funcionalidad no es tan importante, la sacás del siguiente sprint. Si descubrís que otra es crítica, la agregás. Eso es Agile en la práctica.

Scrum define tres roles, pero en equipos pequeños algunos se pueden fusionar:

• Product Owner: dueño del backlog (lista de tareas pendientes). Decide qué entra en el sprint y qué prioridad tiene. En un equipo pequeño, puede ser el fundador, el PM o alguien del equipo técnico que tenga visión de producto.
• Scrum Master: facilitador. Se asegura de que el proceso Scrum se siga y de que las reuniones sean útiles, no burocracia. En equipos pequeños de 3-5 personas, este rol suele ser compartido o innecesario — el mismo Product Owner puede facilitar.
• Equipo de desarrollo: quienes hacen el trabajo. En Scrum puro, este equipo es cross-functional (tiene todas las habilidades necesarias para completar el sprint sin depender de otros). En la práctica, equipos pequeños a veces dependen de una persona externa (diseñador freelancer, etc.) — no es ideal, pero se puede trabajar con eso.

Un sprint sigue este ciclo (adaptado a equipos pequeños):

1. Sprint planning (1 hora): al inicio del sprint, el equipo revisa el objetivo, decide qué tareas entra en el sprint y se compromete a completarlas. No es una promesa de hierro — es un compromiso en base a la información disponible.
2. Daily standup (15 min): cada mañana, el equipo se reúne 15 minutos para responder tres preguntas: ¿qué hice ayer? ¿qué haré hoy? ¿qué me está bloqueando? No es un reporte al jefe, es sincronización entre pares. Ver daily standup que no sea pérdida de tiempo.
3. Ejecución: el equipo trabaja en las tareas. El Product Owner está disponible para dudas, pero no cambia prioridades a mitad de sprint — eso rompe el compromiso.
4. Sprint review (30 min): al final, el equipo muestra lo que completó y recibe feedback. No es una demo formal — es una conversación sobre qué funcionó y qué no.
5. Retrospectiva (30 min): el equipo discute qué funcionó bien del proceso y qué hay que mejorar en el próximo sprint. Ver formatos de retrospectiva.

Scrum "de manual" tiene más ceremonias de las que un equipo pequeño realmente necesita:

• Backlog grooming: una reunión específica para limpiar el backlog. En equipos pequeños, esto se hace de forma continua — el Product Owner mantiene el backlog limpio sin una reunión formal.
• Scrum de Scrum: reunión entre Scrum Masters de varios equipos. Si tu equipo es uno solo, esta reunión no tiene sentido.
• Daily standup formalizada al extremo: si el equipo trabaja en la misma habitación y se comunica todo el día, la daily puede ser innecesaria. Si el equipo es remoto, la daily es útil, pero no tiene que ser estrictamente "cada mañana a las 9am" — puede ser cuando el equipo lo necesite.

La regla de oro: si una ceremonia no aporta valor, sacala. Scrum es un medio, no un fin.

Scrum y Kanban resuelven problemas distintos. Scrum te da un ritmo fijo (sprints) y forzante (compromiso). Kanban te da flujo continuo y visibilidad del trabajo en curso. Si tu equipo se dispersa fácilmente sin ritmos regulares, Scrum. Si prefiere trabajar sin interrupciones artificiales, Kanban. Comparativa completa en Scrum vs Kanban.