5 Puntos para tener buena Sprint Planning

Regresando a nuestro principios, recordamos que en Libre Scrum fue creado para facilitar la vida a nuestros seguidores en lo posible, intentamos brindar información de una manera clara y precisa como si fuese un dulce que pueden llegar y comer en esos pequeños descansos en los que nadie los está mirando. Y es por eso que a pesar de que nuestra estructura suele incluir con frecuencia términos complicados, párrafos interminables y un ritmo de publicación inestable, solemos llegar al cierre con lo único que realmente nos importa al consumir información: Las ilustraciones amarillas que terminan por saltarse las reflexiones y resumir todo de manera cómoda.

Entendiendo entonces nuestro objetivo de entregarles valor es que hemos decidido volver a nuestro origen, preguntándonos ¿Cómo podemos ayudar a nuestro público objetivo (El conocedor de Scrum) a ejecutar este marco de trabajo de mejor manera? Y el razonamiento fue más o menos así: «La mejor medida de que Scrum está funcionando, es sabiendo que está generando un buen incremento, la única manera de generar un buen incremento es mediante un Sprint exitoso, y la mejor forma de poder organizar un Sprint exitoso es con una buena planificación de Sprint«.

Y sí, podríamos ir mucho más atrás. Hasta la escritura de historia de usuario, la priorización y el rol del dueño del producto, incluso a evaluar si es realmente correcto que estés utilizando este marco de trabajo. Pero eso ya viene siendo la «precuela«, y la verdad es que ahí podría calzar mucho mejor un trabajo de consultoría que la autoayuda metodológica de internet (Creo que esa era nuestra clasificación formal ¿Verdad?).

Por eso hoy, como les mencionábamos, volvemos al principio, pero al principio del Sprint. Con una lista sencilla y bonita, que cabe perfectamente en una de nuestras infografías para ayudarte a hacer buenas Sprints Plannings.

¿Qué es la Sprint Planning?

Ya sabemos que lo sabes, pero la formalidad hacia los nuevos lectores mantiene el gancho para que sigan leyendo nuestros artículos… Así que… La Planificación de Sprint es una ceremonia donde el equipo Scrum revisa los requerimientos priorizados del Product Backlog y define cuáles tomarán como Sprint Backlog. Es decir, tomamos una porción del trabajo total, la más importante y mejor priorizada, y definimos un plan de cómo la abordaremos en nuestra próxima iteración.

Sencillo y bonito ¿Verdad? Pues no. Esta ceremonia suele ser por mucho la más larga y tediosa del marco de trabajo. Por libro son ocho horas en promedio para una iteración de un mes, o sea que hay que estar casi toda la mañana discutiendo para un sprint promedio, que se suele traducir en dos semanas. Eso sin contar el tiempo perdido cuando las historias vienen con dependencias, sin relación entre sí, divididas por silos, sin la información necesaria, o con la información suficiente para generar discusiones entre la mitad A y la B de nuestro «autoorganizado» equipo.

Pero no desesperes. Hay ciertos consejos o pasos que pueden hacer que esta ceremonia sea mucho más amena y productiva, y que en equipos maduros suelen recaer en cada integrante. Ahora, si tienes la fortuna de ser el Scrum Master, seguramente ya los conozcas, pero igual toma nota; primero, porque necesitamos que revises a conciencia para ver si encuentras algo de valor; y segundo, por que al que le tocará facilitar y fomentar todo esto será a ti:

1) Has Refinamientos
Ya lo hemos dicho antes y lo repetimos: Divide el trabajo y vencerás. No hay por qué tener una sesión interminable cuando puedes tener múltiples sesiones más pequeñas que te permitan adelantar trabajo. Apóyate con tu Product Owner (O tu Analista de negocio si tienes alguno), y genera sesiones en las que puedan comprobar los nuevos requerimientos con tiempo y con calma, y si estás aplicando estimación, asegúrate de que estos lleguen estimados a la Planificación para evitar contratiempos.

Ahora, en el mundo ideal suena sencillo, pero la verdad es que es muy duro llegar a la planificación con todas las historias refinadas. Debido a esto, no está de más tomarnos los primeros minutos para revisar una que otra historia faltante y aprovechar de que el equipo defina cómo puede realizarla, pero siempre recomendaremos que la mayoría de este trabajo sea hecho previamente. (Si quieres saber más sobre el refinamiento, revisa este artículo).

2) Verifica la capacidad de tu equipo
Asumimos que para este punto tienen un buen lote de requerimientos listos para ser tomados, pero ¿Cuántos tomamos? Lo que dicte la capacidad de tu equipo. Para eso los gráficos de velocidad de los Sprints pasados suelen ser de gran ayuda. Intenta sacar un promedio basado en la experiencia que has tenido con las iteraciones pasadas, recuerda que este marco de trabajo descansa sobre el empirismo, y según eso lleva un control de cuánto más o menos puede tomar el equipo.

Asegúrate eso sí, de revisar la cantidad de días feriados, vacaciones o las batallas de Paintball que estén programadas para la iteración que viene, ya que todo eso te resta capacidad real, y siendo sinceros, nadie quiere estar corriendo después de trabajo para terminar lo pendiente. Nuestro ritmo de trabajo debe ser sostenible.

Además, al momento de comprometerse con requerimientos, asegúrate de que estos añadan valor a negocio y correspondan con las capacidades que tiene tu equipo. Ojo ahí, no vamos a tomar lo que tenemos que tomar, sino que lo podemos tomar según nuestra experiencia.

3) Define con tu equipo el Sprint Goal
Es decir, la necesidad concreta del negocio, que se alinea con cada actividad que realizamos, desde las tareas más pequeñas hasta la estrategia general de nuestro producto. Es importante que nuestro objetivo sea sea definido, que sea entendido y que sea compartido por todo el equipo de trabajo, ya que nos ayuda a mantener el enfoque, el compromiso, el valor para superar los obstáculos, la transparencia sobre de su seguimiento y el respeto con nosotros mismos y nuestro cumplimiento. (¿Les suena conocido?)

Y sí, tal vez esto suene demasiado obvio, después de todo está en toda la literatura más básica, pero lo recalcamos porque hemos visto equipos que simplemente no lo hacen, y consideramos que no está de más recordarlo. Definir por qué hacemos las cosas resulta no sólo provechoso, sino que además es una guía para nuestro día a día.

4) Valida el Definition of Ready
Entonces sabemos más o menos lo que vamos a tomar y el porqué. Pero ¿Realmente podemos tomarlo? Revisa que los requerimientos conversen con la DEFINITION OF READY, aquella lista de condiciones que debe cumplir cada historia para poder ingresar al Sprint. Por lo general, se trata de una lista que cada equipo arma en sus primeras etapas para fomentar la comunicación y hacer la planificación de manera más orgánica (En conjunto con el Definition of Done, tal vez más adelante toquemos un artículo al respecto).

Si no la tienes, pues organiza un tiempo con tu equipo para armarla en conjunto, no podemos decirte específicamente cómo hacerla, pero puedes intentar orientar al equipo a incluir detalles como que «Todos los requerimientos deben…«: Estar en formato de historias de usuario, haber sido estimados, incluir criterios de aceptación, pesar menos de X cantidad de puntos, cumplir con parámetros de escritura, etc.

5) Asegúrate que todo el equipo esté de acuerdo
Hasta ahora, tal vez suene como una larga sucesión de actividades para algo que en inicio debiese ser sencillo, y la verdad es que lo es. Nada de lo dicho está prescrito para asegurar una planificación perfecta para cada iteración, pero son puntos que ayudan a controlar mejor algunos de los múltiples focos de incertidumbre que tendremos en esta ceremonia.

Recordemos que la planificación, además de definir nuestras actividades, termina siendo un compromiso que tomamos todos como equipo, y como me dijeron en una segunda cita «nadie quiere comprometerse con algo que no conoce.» Es por eso que recomendamos estas medidas no sólo para mejorar nuestro rendimiento y aprovechar mejor nuestros tiempos, sino que para reducir los supuestos y aumentar las certezas. Y te sugerimos que antes de cerrar esta ceremonia, hagas un doble vistazo, preguntándole a todo el equipo si se sienten conformes con la planificación realizada, o si tienen algún punto que les gustaría añadir o alguna historia sobre la que dudan demasiado que tal vez deberían negociar nuevamente.

Y hasta aquí llegamos el día de hoy. Esperamos que este artículo te sea de utilidad a la hora de facilitar tu próxima planificación de Sprint, o de tirarle las orejas a tu Scrum Master porque no te gusta como lo está haciendo. Como hemos dicho antes, nuestra intención es hacer lo posible por facilitarte la vida.

Si te interesa aprender más sobre Scrum y el origen de la Sprint Planning, te recomendamos mucho «Scrum, el arte de hacer el doble de cosas en la mitad del tiempo«. Si por otra parte, quieres aprender sobre el principal mecanismo de mejora de Scrum, quizás «Retrospectivas: Haciendo buenos equipos, mejores» sea una mejor sugerencia. Y si te interesa contactarte con un equipo que apoye a tu organización a adoptar una cultura más adaptable a la errática realidad, te recomendamos enviarle un mensaje a nuestro partner BlackHat y ver qué opciones pueden ofrecerte. Feliz día a todos!