Guía
Scrum
Scrum es un marco corto —cabe en unas pocas páginas— para entregar en iteraciones. Casi todos los problemas con Scrum vienen de aplicar la ceremonia sin entender qué problema resuelve cada parte.
Última actualización:
Scrum organiza el trabajo en *sprints* de una a cuatro semanas. Al final de cada uno debería haber algo terminado y potencialmente entregable. La idea es tener un punto de inspección frecuente y fijo.
Roles
- Product Owner: decide qué se hace y en qué orden. Es una persona, no un comité, y tiene autoridad real sobre la prioridad.
- Scrum Master: se ocupa de que el proceso funcione y de retirar los obstáculos. No es un jefe de proyecto ni asigna tareas.
- Equipo de desarrollo: quienes construyen. Se organizan ellos mismos para cumplir el objetivo del sprint.
Eventos
- Planificación: el equipo elige cuánto trabajo entra en el sprint y define el objetivo.
- Daily: quince minutos para sincronizarse y detectar bloqueos. No es un informe de estado para el jefe.
- Review: se enseña lo terminado a quien corresponda y se recoge *feedback*.
- Retrospectiva: el equipo mira cómo ha trabajado y elige una o dos mejoras concretas para el siguiente sprint.
Artefactos
El product backlog es la lista priorizada de todo lo pendiente, viva y a cargo del Product Owner. El sprint backlog es lo que el equipo se ha comprometido a hacer en el sprint en curso. El incremento es la suma de todo lo terminado hasta la fecha, en estado entregable.
Antipatrones habituales
- Sprints que terminan con trabajo «casi hecho» que se arrastra: la definición de «terminado» no es real.
- El daily convertido en reunión de reporte a un mando: deja de servir para coordinarse.
- Un Product Owner sin autoridad que tiene que consultar cada prioridad: el cuello de botella se traslada fuera del equipo.
- Retrospectivas que no cambian nada: si nadie actúa sobre las mejoras, el equipo deja de proponerlas.
- Estimar para medir productividad: la estimación se infla y pierde su función.
Preguntas frecuentes
Lo que suelen preguntarnos
¿Cuánto debe durar un sprint?
Entre una y cuatro semanas, siempre la misma duración. Dos semanas es lo más habitual: suficiente para terminar algo, corto para corregir rumbo pronto.
¿El Scrum Master puede ser también del equipo de desarrollo?
Puede, en equipos pequeños, pero hay tensión de agenda: cuando aprieta la entrega, el trabajo de proceso se abandona. Si se combina, hay que protegerlo de forma explícita.
¿Scrum sirve para mantenimiento y soporte?
Peor que Kanban. El trabajo urgente e imprevisible rompe el compromiso del sprint. Para eso, Kanban con límites de trabajo en curso encaja mejor.
¿Se puede hacer Scrum sin Scrum Master?
Se puede, pero alguien tiene que ocuparse de que las reuniones aporten y de retirar bloqueos. Si nadie lo hace, el proceso se degrada en pocas semanas.
Servicios relacionados
Guías relacionadas
Seguir leyendo
Siguiente paso
Media hora bien invertida
Cuéntanos el problema en una llamada corta. Salimos con una primera orientación de por dónde iría y qué implicaría, sin compromiso y sin presentación comercial.