Cambios entre las ediciones de 2011 y 2013 de Scrum

El pasado julio los padres de Scrum, Ken Schwaber y Jeff Sutherland, pusieron a disposición del mundo una nueva versión de la “Guia de Scrum”, versión que, por el momento, sólo podemos encontrarla en inglés (aquí tienes el enlace a la versión en español)
Estos son, de manera muy resumida, los cambios principales y más destacados respecto a la versión anterior, la de octubre de 2011:
1 – Ahora todos los eventos son “time-boxed” (duración fija), es decir, cada uno de ellos tiene una duración máxima y definida. Un Sprint, tiene una duración que no puede recortarse o alargarse, en cambio, el resto de eventos, si pueden terminar antes de su duración máxima si el objetivo se ha alcanzado.
2 – Se refuerza la importancia del Daily Scrum como evento de planificación. ya que, con demasiada frecuencia, se piensa en él como un evento de situación y estado. Los datos de entrada a esta reunión deberían ser cómo se está trabajando para alcanzar el Sprint Goal, y el resultado será un plan nuevo o revisado que optimize los esfuerzos del equipo para cumplir con el Sprint Goal. Para conseguirlo, se han reformulado las tres cuestiones que debían contestarse en el “daily”, haciendo más énfasis en el equipo que en el individuo:
a)     ¿Qué hice yo ayer que ayudó al equipo de desarrollo a alcanzar o aproximarse al Sprint Goal?
b)     ¿Qué haré hoy que ayude al equipo de desarrollo a acercarse más al Sprint Goal?
c)     ¿Veo algún impedimento que no me permita a mí o al equipo de desarrollo alcanzar el Sprint Goal?
3 – Sprint Planning Meeting, cambia de nombre, siendo ahora sólo Sprint Planning.
4 – El Sprint Planning deja de estar formado por dos sub-eventos, para estar formado por uno… solo con dos temas a tratar: ¿Qué podemos hacer este Sprint? Y ¿Cómo se harán las tareas? Después de que el grupo de desarrollo defina las tareas del Sprint Backlog, el equipo definirá el Sprint Goal, que permite a todos los miembros del equipo tener un objetivo común.
5 – El concepto del valor se refuerza mediante el uso del Sprint Review. Durante el Sprint Review, el equipo y los stakeholders colaboran para ver que se ha hecho durante el Sprint. En base a lo que se ha realizado y a los cambios que se hubieran podido producir en el Product Backlog, los asistentes colaboran para definir cómo optimizar el valor.
6 – Nueva sección a la guía, “Artifact Transparency”, que habla sobre como Scrum se basa en la transparencia. Si la transparencia aumenta, aumenta la solidez de las decisiones. Si la transparencia no es completa, las decisiones pueden ser erróneas, aumentando el riesgo y disminuyendo el valor.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba