Sprint Planning orientado al compromiso

Hay dos formas básicas de planificar un Sprint:

1) Sprint Planning orientado a la Velocity
(con atención al volumen de trabajo promedio de un equipo), y
2) Sprint Planning orientado al compromiso
(con atención a lo que un equipo cree que puede lograr en un Sprint)

Ya he explicado el Sprint Planning orientado a la Velocity, así que aquí nos concentramos en el Sprint Planning orientado al compromiso:

Las reuniones de Sprint Planning orientadas al compromiso involucran al Product Owner, al Scrum Master y a todo el equipo de desarrollo. El Product Owner da una visión general de los Product Backlog Items con mayor prioridad y luego los explica al equipo.

Seleccionar un elemento

A continuación, los miembros del equipo seleccionan un elemento para el próximo Sprint. En la mayoría de los casos, coincide con el elemento al que el Product Owner también ha dado la mayor prioridad. Sin embargo, también puede ocurrir que el elemento del Product Owner aún tenga demasiados puntos sin resolver.

Idealmente, el equipo debería poder incorporar este elemento al Sprint y resolver las preguntas abiertas lo suficientemente pronto como para poder completar el elemento de todos modos. Sin embargo, si hay demasiados puntos por resolver, demasiado graves o demasiado lentos, entonces el elemento seleccionado por el Product Owner debería posponerse.

Tasks y horas

Una vez seleccionado un elemento, los miembros del equipo discuten el trabajo asociado e identifican los Tasks (tareas) necesarios para poder entregar el Product Backlog Item. Durante o inmediatamente después, el equipo estima cuánto tiempo (horas) necesitarán aproximadamente para los Tasks individuales.

Pero no esperes que el equipo dé una estimación para cada Task. Eso no solo es imposible, sino también innecesario.

Los miembros del equipo solo deben estimar suficientes Tasks para tener la sensación de haberlo pensado todo lo suficiente. Porque ese es el verdadero objetivo de una reunión así. Definir Tasks y números de horas es secundario.

La pregunta sobre los compromisos

Una vez que los miembros del equipo han definido los Tasks y pueden estimar aproximadamente cuánto tiempo necesitarán para determinados Backlog Items, deberían hacerse la pregunta: "¿Podemos dar un compromiso para esto?"

Considero importante que el equipo se haga esta pregunta a sí mismo y no sea el Scrum Master quien pregunte: "¿Pueden dar un compromiso para esto?" Porque de esta manera se comprometen entre sí, en lugar de comprometerse ante el Scrum Master.

No sé cómo será en tu caso, pero mis primeros años en la vida profesional (en la época anterior a Scrum) estuvieron marcados por compromisos imposibles de cumplir ante superiores que preguntaban "¿Puede usted lograrlo?" pero en realidad querían decir "¡Asegúrese de lograrlo!"

Aunque el Scrum Master se denomina "Master", no es un superior del equipo y tampoco debería dar esa impresión. Es mejor no ser visto como un jefe que insiste en el cumplimiento de todos los compromisos.

En su lugar, el equipo debería ser llevado a preguntarse a sí mismo: "¿Podemos dar un compromiso?" Porque un compromiso es mucho más fuerte cuando el equipo se compromete consigo mismo.

Además, está claro que a la pregunta del equipo "¿Podemos dar un compromiso?" solo puede haber dos respuestas posibles: "Sí, podemos" o "No, no podemos". En cambio, si el Scrum Master pregunta "¿Pueden dar un compromiso?", algunos miembros del equipo responderán con "nosotros" y otros con "yo".

Scrum requiere un compromiso de todo el equipo: "Si necesitas ayuda, te ayudaré y sé que tú harías lo mismo por mí" y no "Estos son mis Tasks y esos son los tuyos".

Repetir el proceso con más historias

Si el equipo está de acuerdo en que puede dar un compromiso para un determinado Product Backlog Item, selecciona otro elemento y repite el proceso Tasks – Horas – Compromiso, hasta que alguien diga que no puede dar un compromiso para el elemento seleccionado.

Si es así, los miembros del equipo discuten la situación y ven si tal vez alguien más puede ayudar. Quizás un administrador de bases de datos con conocimientos rudimentarios de JavaScript pueda ayudar a un desarrollador JavaScript sobrecargado.

Si ese no es el caso, la historia puede devolverse al Backlog y seleccionar un elemento más pequeño o sencillo al que todos puedan comprometerse.

¿Qué pasa con los Story Points y la Velocity?

Quizás ya hayas notado que en este proceso ni los Story Points ni la Velocity han jugado un papel hasta ahora. Sigo recomendando estimar los Product Backlog Items con ayuda de Story Points. Sin embargo, los Story Points y la Velocity no juegan un papel real hasta este punto en el Sprint Planning orientado al compromiso. Sí juegan un papel importante en la última fase de una reunión de Sprint Planning.

Verificación de plausibilidad de los compromisos

Una vez que el equipo ha llenado el tiempo disponible en un Sprint, el Scrum Master puede verificar cuántos Story Points recibieron previamente los elementos individuales. Luego comparte el resultado con el equipo. El equipo puede comparar esta cifra con su Velocity promedio o actual.

Supongamos que un equipo con una Velocity promedio de 20 celebra una reunión de Sprint Planning de este tipo y selecciona elementos que suman un total de 19 Story Points. Han seleccionado estos elementos sin saber cuántos Story Points se les habían asignado previamente.

Cuando el Scrum Master les comunica que acaban de seleccionar elementos con un total de 19 puntos y que su Velocity promedio es igual o muy similar, los miembros del equipo pueden asumir que han planificado la cantidad correcta de trabajo para el Sprint.

Sin embargo, si solo se seleccionaron elementos con un total de 11 Story Points, deberían preguntarse por qué ahora consideran el trabajo mucho más difícil.

Esto podría deberse, por ejemplo, a que durante el Sprint Planning identificaron trabajo que no habían considerado antes. O simplemente descubren que una historia es en realidad más complicada de lo que pensaban.

En cualquier caso, el equipo sabrá si ha elegido una cantidad adecuada de trabajo o si quizás puede planificar aún más.

Por otro lado, los miembros del equipo se preguntarán qué no han tenido en cuenta si han seleccionado elementos con un total de 30 puntos, es decir, 10 más que su promedio. La pregunta podría ser: "¿Por qué este trabajo parece mucho más fácil después del Sprint Planning que antes?"

La Velocity y los Story Points, por tanto, no juegan ningún papel durante la mayor parte de una reunión de Sprint Planning orientada al compromiso. Sin embargo, son indispensables cuando se trata de verificar y confirmar la planificación.

Un compromiso no es una garantía

Es importante no ver nunca un compromiso como una garantía. Como dijo Clint Eastwood en una de sus películas: "¡Si quieres una garantía, cómprate una tostadora!"

El compromiso de un equipo significa que todos dan lo mejor de sí. Si pueden cumplir sus compromisos en el 80 por ciento de los casos, es un buen promedio. También significa que deben tomarse el asunto en serio y usar el tiempo de manera óptima. Esto crea confianza en el equipo y en lo que dice que puede lograr.

Sin embargo, el objetivo no debería ser terminar siempre todo al 100 por ciento. Un equipo que se ve obligado a terminar siempre todo podrá lograrlo, pero solo estableciendo compromisos más bajos.

He llamado a este enfoque "Sprint Planning orientado al compromiso". También se conoce como "Planificación basada en la capacidad". Este término me gusta cada vez más, porque un compromiso puede entenderse fácilmente como una garantía.

Este texto proviene del blog de Mike Cohn y fue traducido al alemán por nosotros.