Los compromisos del Sprint son fijos, excepto cuando no lo son.

• enero 30, 2015• 5 min•

El título de este post tiene algo de contradicción, pero me siento bien contradiciéndome de vez en cuando. En el grupo de LinkedIn de  Certified ScrumMaster hubo una interesante conversación sobre lo que debe hacer un equipo cuando terminan todo su trabajo antes del final del Sprint. Otras personas habían comentado antes sobre el tema algunas estrategias eficaces y mi única contribución fue que si el equipo ha terminado, deben ayudar a otros miembros del equipo u otros equipos que no lo han hecho.

Entonces el hilo del tema tomó un giro más interesante cuando un participante citó Jeff Sutherland en su reciente libro, Scrum: The Art of Doing Twice the Work in Half the Time, y citó un pasaje específico que dice que el alcance de un Sprint está cerrado después de la planificación del Sprint . Si bien en la mayoría de situaciones, yo tendería a estar de acuerdo con que Scrum, debe ser seguido según la teoría, dice que una vez el compromiso del equipo para el objetivo del Sprint queda establecido en la planificación del Sprint, no puede ser alterado. Si permitimos un exceso de flexibilidad, eso creará demasiado trabajo basura y falta de enfoque en el equipo. Además, dejando al negocio cambiar las prioridades después de la planificación del Sprint no fomenta que el mismo haga compromisos con respecto a sus prioridades, ni a reforzar la responsabilidad del Product Owner para estar listo y preparado a tiempo para la planificación del Sprint.

Sin embargo, después nos encontramos con Scrum en la práctica y las cosas se vuelven un poco más desordenadas. Cuando trabajo con equipos y organizaciones, me encuentro con varios escenarios que se repiten con bastante frecuencia en los que se sugiere la necesidad de flexibilizar las reglas (sin llegar a romperlas). Si Scrum no le sirve a la empresa, entonces el negocio no va a apoyar la aplicación continuada de Scrum. Sin embargo, también tenemos que ser disciplinados en nuestra aplicación de Scrum porque entonces se convierte en cualquier cosa que digamos que es y ese no funciona tampoco.
Cuando se flexibilizan las reglas de Scrum, nuestra solución debe basarse en los valores y principios de Scrum y continuar cumpliendo los diversos derechos de cada rol. En estos tipos de situaciones en las que el alcance y las prioridades cambian, hay tres principios que vienen a mi mente. En primer lugar, el Product Owner tiene derecho a recibir el máximo valor todas las semanas. En segundo lugar, las partes interesadastienen derecho a cambiar de opinión, sustituir funcionalidad y alterar las prioridades sin tener que pagar un costo exorbitante. En tercer lugar, tenemos que mantener el enfoque de equipo y evitar interrupciones y distracciones lo más posible. Estos tres principios tienen que equilibrarse contra la regla en Scrum que dice: “Una vez que el equipo se compromete a la meta del Sprint no puede ser alterado.”
Ahora para mis escenarios.
  1. El equipo termina su compromiso temprano – en este caso el Product Owner tiene el derecho de tomar un pequeño elemento del Product Backlog que puede estar 100% terminado, es decir, cumple con la definición de “done”, antes del final del Sprint. No coger un elemento sólo para obtener una ventaja en el próximo Sprint de lo contrario el producto no sería potencialmente entregable al final del Sprint.
  2. El Product Owner reconoce que un Elemento del Product Backlog (PBI) no tiene que ser entregado – en este caso el Product Owner puede optar por cambiar el PBI (Product Backlog item) por otro PBI más valioso de igual o menor tamaño. Tenemos que reconocer que las prioridades cambian en el negocio y si realmente un elemento no se necesita , el negocio no debería tener que pagar por algo que no quieren ni necesitan. Yo llamo a este intercambio de un elemento sin empezar por un elemento diferente en el Product Backlog “el intercambio”. No es un reemplazo para la mala preparación por parte del Product Owner. Además, si el elemento se ha iniciado y la empresa decide que no lo quiere, es demasiado tarde – no hay intercambio.
  3. El equipo se entera de que la tecnología no soporta el elemento – mucha de la planificación Scrum en Scrum es especulativa y basada en hipótesis de lo que es posible con la tecnología. De vez en cuando, la tecnología simplemente no funciona. En este caso el propietario del producto puede simplemente eliminar el PBI del alcance del compromiso del equipo y puede seleccionar un nuevo PBI de tamaño igual o menor, si es aceptado por el equipo. Otra opción para el equipo y el Product Owner es reemplazar el elemento con un Spike. Los Spikes no son sustitutos para la diligencia de ingeniería por parte del equipo.
  4. El objetivo del Sprint ya no ofrece al negocio ningún valor – en este caso el Product Owner puede optar por una terminación del Sprint y re-plantear un nuevo objetivo del Sprint con el tiempo restante en el mismo. En mis diez años de Scrum, sólo he usado una terminación Sprint una vez y fue debido sobre todo a mi propio ego. En casi todos los casos, algo de valor se puede salvar sin terminar el Sprint. Sin embargo, considero la terminación del Sprint el mazo que se usa cuando todo está absolutamente hecho una “mierda”