Anexo. Scrum en una página
Scrum sirve para que un equipo aprenda mientras entrega un producto cuyo resultado no se puede saber de antemano. Cada Sprint termina con algo que se puede usar y con evidencia para decidir el siguiente paso. Si el trabajo se puede predecir de principio a fin, Scrum deja de aportar un valor diferencial (capítulo 1).
Responsabilidades del equipo Scrum
- Product Owner: el valor. Decide qué se hace, en qué orden y por qué.
- Desarrolladores, con sus agentes: la calidad. Deciden cómo se hace y responden de que esté hecho.
- Scrum Master: que el equipo funcione y mejore. Quita lo que lo frena.
Las metas dirigen el desarrollo
Cada meta cuelga de la anterior (capítulo 15):
- Meta de la empresa: lo que la organización quiere conseguir.
- Product Goal: qué cambio en el comportamiento de los usuarios persigue el producto.
- Sprint Goal: qué aporta este Sprint a ese cambio.
Los eventos, por lo que deciden
- Release Planning: cómo llegamos, con uno o más equipos, al Product Goal en el mínimo número de Sprints. Concreta los próximos tres o cuatro y deja el resto como dirección. Las fechas se predicen con el histórico de los Sprints anteriores; no se prometen (capítulos 11 y 18).
- Sprint: lo más corto que nos permite aprender cómo seguir con el producto. Por el camino suele dejar varios Incrementos (capítulo 12).
- Sprint Planning: qué Sprint Goal nos acerca más al Product Goal, y un plan creíble para lograrlo.
- Daily Scrum: ¿seguimos camino del Sprint Goal? Si no, se replanifica hoy.
- Sprint Review: con quien usa o paga el producto, cómo cambia el plan de la release. No es una demo: las validaciones se obtienen durante el Sprint.
- Sprint Retrospective: qué cambiamos en cómo trabajamos, también con los agentes.
Los artefactos, por lo que los orienta
- Tablero de coordinación, orientado por la meta de la empresa. Tiene tres niveles, como en Flight Levels: la estrategia, la coordinación entre equipos (iniciativas y dependencias) y el trabajo de cada equipo. Enseña dónde se atasca el valor y quién decide el orden.
- Product Backlog, orientado por el Product Goal. Todo lo que hay en él existe para acercarse a esa meta; lo que no, sobra.
- Sprint Backlog, orientado por el Sprint Goal. Es el plan del Sprint, y cambia cuando cambia lo que sabemos.
- Incremento, orientado por la Definition of Done. Solo cuenta lo que la cumple, lo haya escrito una persona o un agente (capítulo 14).
El Release Planning y el tablero de coordinación no están en la Guía Scrum, que deja fuera el medio plazo para servir en cualquier contexto. Con un producto real y varios equipos hacen falta.
La prueba
Scrum funciona si cada Sprint deja algo usable y una decisión tomada con evidencia. Si solo deja tareas cerradas, es una fábrica de tickets.