Introducción a Scrum: roles, eventos y artefactos sin complicarte

Scrum es el marco ágil más extendido. Su guía oficial, la Scrum Guide, ocupa pocas páginas a propósito: es un marco ligero, no una metodología completa. Define lo mínimo para trabajar en ciclos cortos con un equipo autónomo y deja el resto a cada equipo.

La idea central

En lugar de planear todo y esperar al final, trabajas en ciclos de duración fija, llamados Sprints (normalmente de una a cuatro semanas). Al final de cada Sprint tienes un incremento del producto utilizable y aprendes qué ajustar. Scrum se basa en empirismo: transparencia (todos ven lo mismo), inspección (revisar con frecuencia) y adaptación (cambiar cuando haga falta).

Los roles

Scrum define tres responsabilidades:

| Rol | Qué hace | |---|---| | Product Owner | Es dueño del qué. Define y ordena por valor la lista de trabajo del producto | | Scrum Master | Ayuda al equipo a entender y usar Scrum, y quita obstáculos. No es un jefe | | Developers | Construyen el incremento. Se organizan solos para decidir cómo hacerlo |

Juntos forman el Scrum Team: un equipo pequeño y multifuncional, con todas las habilidades necesarias para entregar.

Los artefactos

• Product Backlog: lista ordenada de todo lo que podría hacerse en el producto. Es dinámica y la gestiona el Product Owner.
• Sprint Backlog: lo que el equipo se compromete a trabajar en el Sprint, más su plan.
• Incremento: el resultado utilizable al final del Sprint, que cumple la definición de terminado acordada.

Cada artefacto tiene un compromiso asociado: una meta para el producto, una meta del Sprint y la definición de terminado.

Los eventos

1. Sprint: el contenedor de todo lo demás.
2. Planeación del Sprint: se elige qué trabajar y se define la meta.
3. Scrum Diario (Daily): 15 minutos para sincronizar el plan de las próximas 24 horas. No es un informe al jefe.
4. Revisión del Sprint: se muestra el incremento a los interesados y se recibe retroalimentación.
5. Retrospectiva del Sprint: el equipo analiza cómo trabaja y qué mejorará.

Un ejemplo de Sprint de dos semanas

| Día | Qué ocurre | |---|---| | Lunes 1 | Planeación: meta "los clientes pueden consultar el estado de su pedido" | | Cada día | Daily de 15 minutos, trabajo, revisión de código | | Viernes 2 (final) | Revisión con interesados y retrospectiva |

Qué hace valioso a Scrum

• Ciclos cortos obligan a entregar y mostrar con frecuencia.
• La priorización continua evita construir lo menos importante.
• La retrospectiva institucionaliza la mejora.
• El equipo autónomo decide cómo trabajar, lo que aumenta compromiso.

Errores comunes

• Scrum Master como jefe de proyecto que asigna tareas.
• Product Owner ausente o sin capacidad de decidir, que bloquea al equipo.
• Daily como informe de estado a un gerente.
• Sprints que nunca terminan: se extienden o se arrastran tareas sin entregar nada utilizable.
• Saltarse la retrospectiva porque "no hay tiempo", que es cuando más hace falta.
• Medir a las personas con la velocidad. La velocidad sirve al equipo para proyectar, no para compararse con otros equipos.
• Ceremonia sin cambio de fondo: reuniones de Scrum, pero decisiones tomadas arriba, igual que antes.

Cuándo no es la mejor opción

Si el trabajo es continuo y de flujo constante (soporte, operaciones) más que de proyectos con objetivos por ciclo, quizá Kanban encaje mejor. Y si el equipo no puede ni quiere autonomía, adoptar Scrum solo cambiará los nombres.

Para finalizar

Scrum es simple de entender y difícil de practicar bien. Los eventos y roles son lo de menos; lo que importa es que el equipo vea su trabajo, entregue cada poco tiempo, escuche a los usuarios y mejore de forma deliberada. Si estás empezando, adopta el marco tal cual durante algunos Sprints, y luego adapta con base en lo que aprendas. Siguiente artículo: Kanban, la alternativa centrada en el flujo.