Recientemente Scrum.org, la organización detrás de la difusión de la metodología, publicó la versión actualizada de la guía escrita originalmente por Jeff Sutherland y Ken Schwaber y revisada este año: Scrum Guide 2011.
En la misma página se encuentran disponible traducciones de la guía a muchos idiomas, incluyendo la versión en español (PDF, versión del 2010).
Para quienes no conocen más que lo anecdótico de Scrum, dejo un brevísimo resumen de este framework que se basa en tres pilares:
- Transparencia
- Inspección
- Adaptación
El equipo de Scrum está compuesto por:
- El Product Owner (PO, dueño del producto), que se ocupa de maximizar el valor del producto y el trabajo del equipo de desarrollo. Por eso es el responsable principal del Backlog de producto, y debe asegurarse que esta lista está siempre priorizada, de manera que nadie trabaje en lo que no es la máxima prioridad en cada momento.
- El Equipo de Desarrollo es el grupo que se encarga de entregar incrementalmente un producto funcional al fin de cada Sprint (iteración). La guía agrega un poco más de detalle incluyendo la composición y tamaño.
- El Scrum Master se encarga de que las reglas y principios de Scrum se mantengan y de que los bloqueos potenciales se eviten o eliminen cuanto antes. La guía detalla un poco más los servicios que el Scrum Master proporciona al PO, al Equipo de Desarrollo y a la Organización.
Los eventos de Scrum son:
- El Sprint (o iteración) durante el que el compromiso asumido por el equipo y consensuado por el PO no debe cambiar, y se ejecuta manteniendo el orden de prioridad para el negocio, de manera de que al terminar el límite de tiempo impuesto (entre una semana y un mes) lo que quedó completo e incluido en el incremento de producto es siempre lo más importante. Dentro del Sprint se producen:
- La planificación del Sprint, en el inicio, donde el Equipo y el PO acuerdan el compromiso para la iteración, tomando los ítems de máxima prioridad en el Backlog de Producto, en orden descendente, hasta donde el equipo estima que puede terminar dentro del límite de tiempo.
- El Scrum Diario (o stand-up), donde el equipo se reúne (de pie, para evitar prolongar la reunión más de unos minutos) y cada miembro del equipo expone:
- Qué terminó desde el último stand-up
- Qué planifica terminar antes del próximo stand-up
- Qué obstáculos puede llegar a tener (y que el Scrum Master deberá evitar que bloqueen al equipo)
- El Sprint Review, en el que el equipo muestra el resultado del trabajo al PO y los interesados que éste considere apropiado para ayudarlo a continuar ajustando el Backlog de producto.
- La retrospectiva en que el equipo reflexiona sobre la manera en que se desarrolló el trabajo, teniendo en cuenta relaciones, técnicas, herramientas y demás, y determina algunas medidas para mejorar en el siguiente Sprint.
Los artefactos de Scrum son muy pocos:
- El Backlog de Producto, que el PO se encarga de construir y mantener priorizado en base al valor para el negocio a través del tiempo.
- El Backlog del Sprint, que el Equipo y el PO determinan al comienzo de cada Sprint y cuyo seguimiento determina el nivel de avance dentro del Sprint.
- El Incremento de producto es la entrega que el equipo realiza a final de cada Sprint, y que debe ser funcional desde el inicio, de manera que esté potencialmente en condiciones de usarse y agregar valor.
En la guía terminan volviendo a la importancia de la definición de cuándo una tarea está “terminada”, lo que debe convertirse en un contrato entre el Equipo, el PO y la Organización, de manera de ajustar las expectativas y evitar discusiones y problemas al respecto.
La guía amplía un poco este resumen, pero sólo tiene 17 páginas, incluyendo algunas con índice, historia, agradecimientos, etc. El framework es muy sencillo de describir, lo que no implica que sea fácil de implementar. Suele decirse que se parece en eso a un deporte: las reglas son sencillas, pero ser un buen jugador es típicamente un gran desafío y el secreto está en la práctica y la dedicación.
Video
Como final, dejo este video de una charla de Schwaber en el 2006 dentro de las oficinas de Google, que me parece que explica bien muchos de los principios, y aunque está en inglés, vale la pena escuchar esto desde uno de sus iniciadores.
El pasado 19 de julio el grupo 
El 
