El Sprint Planning es una reunión donde el Scrum Team tiene la oportunidad de organizar de la forma más eficiente posible el trabajo para el Sprint. Probablemente, todos somos conscientes que, al iniciarse cada Sprint en nuestro proyecto con Scrum, es necesaria la realización de una reunión con negocio, en la que decidiremos lo qué haremos en ese pequeño periodo de tiempo.

Es posible que algunos miembros de tu equipo no sepan que esta acción de planificación se encuentra circunscrita única y exclusivamente sobre “el cómo”. Por lo que se refiere a las características de la necesidad, su composición, su impacto, su interrelación con otras necesidades y, sobre todo, la comprensión completa de esta por parte del equipo técnico, es una tarea a la cual ya llegaremos preparados al Sprint Planning.

Dicho de otro modo: El Sprint Planning no sirve para adquirir consciencia y conocimiento sobre las necesidades a construir. Y ha de servir solo para que el equipo técnico tenga un espacio para debatir las complejidades de la construcción (debatir “el cómo” de las necesidades finalmente escogidas).

Por tanto, debe haber otro periodo de tiempo para la comprensión y el análisis de la necesidad. Y esto en Scrum se lleva a cabo en el ámbito de otra reunión que explicamos en otro artículo: El Refinement.

Resuelto este inciso. Los técnicos llegan a la reunión con plena comprensión de lo más crítico que, probablemente, escogeremos en esta reunión para su construcción. I digo probablemente por qué, cuándo trabajamos en agilidad, no tenemos una planificación férrea y, por tanto, todo está sometido a cierta negociación y consenso. Y el Sprint Planning es un ejemplo de esta capacidad de negociación entre todas las partes interesadas.

El Sprint Goal

La reunión empieza con una primera pregunta que hay que responder: ¿Cuál es el objetivo de este Sprint? Esto se conoce cómo la definición del Sprint Goal, El protagonista para dar respuesta a esta pregunta, y además, asegurar la comprensión de la finalidad por parte del equipo técnico, es el Product Owner. Él es el responsable de la priorización del Product Backlog y, por tanto, debe haber reflexionado sobre qué ítems de este son más prioritarios para el negocio en este momento.

Pero aquí nunca se ha tratado de que el equipo construya funcionalidades sin contexto. Es precisamente este interés por mantener el contexto de aquello que se está haciendo, o que hace tan recomendable que el Product Owner y los técnicos consensúen un Sprint Goal. Mantener el contexto proporciona una serie de beneficios que todos nosotros deberíamos tener siempre en nuestro punto de mira:

• Motivación de los técnicos: El hecho que los técnicos no solo se centren en adquirir el compromiso para hacer una serie de tareas previstas; sino que participen en la visión global del valor que proporciona a la organización, tiene efectos directos sobre la motivación y la participación de estos en la consecución de un objetivo común. Una meta.
• El MVP: El éxito de un Sprint no recae en la consecución de una serie de hitos previstos; sino en conseguir un incremento de valor para la organización. Este valor se explica, no por las características particulares de cada una de las piezas individuales del incremento, sino por la resolución de una necesidad del negocio. Aunque esta sea pequeña.
• La calidad: El hecho de “planificar” una mejora de como resultado un objetivo preestablecido, facilita el trabajo de los stakeholders a la hora de verificar si hemos conseguido este objetivo. Ya que la validación, mediante los criterios de aceptación, no deben enfocarse cómo la validación de cierto número de piezas tecnológicas obtenidas, sino como el test de uno o diversos escenarios de negocio que dan fe a este objetivo.

Esta definición de la meta del Sprint (Sprint Goal) debe ser una acción que no ocupe más de unos pocos minutos en la reunión de Sprint Planning.

Recoger la funcionalidad

Una vez definido el objetivo del Sprint, la selección de las necesidades a construir debería ser una cuestión más sencilla. Ya que la selección se realizará en función de que cada ítem de o no respuesta a la meta del Sprint. Si el Product Owner ha reflexionado bien su priorización, generalmente no debe haber dificultades en la selección de estas necesidades. Pero volvemos a decirlo: Esto es agilidad. La agilidad ha de llevar siempre pareja la capacidad de debate y consenso de forma no traumática. Es perfectamente posible que el equipo y el Product Owner acaben consensuando un conjunto de necesidades para aquel Sprint que no sea al 100% el que el Product Owner podía imaginarse un tiempo atrás. Existen toda clase de motivos y beneficios para esta negociación:

• Ítems un poco menos prioritarios que cumplen mejor con el Sprint Goal establecido
• Conveniencia técnica o dependencias que hacen aconsejable la selección de un ítem del Product Backlog en relación a otro
• Intereses del negocio en función de la conversación y el debate al momento de definir el Sprint Goal, que han hecho que el Product Owner vea más factible la selección de un ítem de prioridad menor.

Todo es posible. La única premisa es que sea el producto de un diálogo en el equipo.

Asegurar los criterios de aceptación

Los criterios de aceptación son todo aquello que nos permitirá demostrar en el Sprint Review, que hemos llegado al objetivo establecido en este Sprint. Por tanto, es una información primaria para el equipo. El equipo debe preocuparse que esta información sea parte de la definición de las necesidades que hemos escogido construir. Hasta el punto que, si una necesidad no tiene la definición sobre los criterios de aceptación, no se encuentra en un punto que permita que el equipo la pueda construir y, por tanto, no podrá formar parte de la selección comprometida en este Sprint. Esto, que recibe el nombre de Definition of Ready (DoR) lo explicamos en otro artículo.

Los criterios de aceptación, al ser la herramienta que permite a los Stakeholders verificar y validar la correcta comprensión y utilidad de lo que el equipo técnico ha construido; es responsabilidad de los Stakeholders la definición (o redacción, o preparación) de estos criterios de aceptación. Esto es lo que diferencia la cooperación de los usuarios en un proyecto ágil respecto a un proyecto tradicional. El negocio se responsabiliza no solo de “decir lo que quiere” sino de asegurar el entendimiento del equipo técnico sobre cómo lo verificará y validará.

El Sprint Planning es el lugar donde el Scrum Team comprueba la existencia y coherencia de estos criterios de aceptación. Debemos entender los criterios de aceptación desde diversos niveles de actuación. Hay criterios de aceptación a nivel necesidad. Pero tambien deben existir criterios de aceptación a nivel de entrega. Además, es especialmente importante que toda esta tarea de verificación tenga siempre presente la existencia y integración con todas las porciones de producto entregadas con anterioridad.

Organizar el trabajo

Una vez establecido el compromiso sobre qué incremento de valor vamos a llevar a cabo durante el Sprint. Y una vez asegurada y entendida la forma como este incremento será verificado y validado por parte de los Stakeholders; el equipo técnico adquiere el protagonismo de la reunión. El Product Owner puede continuar o no, en función de las dudas que pueda haber, y si el equipo técnico lo cree necesario.

Este espacio de tiempo en la reunión permite al equipo técnico organizar el trabajo que deberá ejecutarse durante el Sprint. Scrum no dice nada sobre cómo debe de procederse ante esta organización. Y aunque actualmente es muy habitual que los equipos desgranen la necesidad en tareas técnicas; no tiene por qué ser la única estrategia posible.

Por otra parte, hay que decir que esta acción de definición de las tareas técnicas de una historia de usuario dada, no es una tarea que el equipo lleva a cabo “en frío” durante el Sprint Planning. Ya que el equipo ya ha trabajado anteriormente la comprensión de aquella historia de usuario con los Stakeholders. Y ya ha trabajado una estimación en esfuerzo para llegar al Sprint Planning con una comprensión completa y, en esta estimación, es seguro que han aparecido tareas, acciones o estrategias de construcción. Ahora, en el Sprint Planning, el equipo hace firme una estrategia concreta de construcción con la definición de las tareas técnicas necesarias.

El volumen de trabajo. La estimación de las historias en el Product Backlog. La Team Velocity

Esta es la cuestión que tanto preocupa a los Projects Managers tradicionales. ¿A cuánto trabajo se compromete el equipo en un Sprint? Aquí pienso que es importante aclarar dos aspectos que son esenciales en agilidad:

1. En agilidad, no nos preocupa el volumen en crudo, sino la consecución de un incremento de valor para la organización en un pequeño periodo de tiempo.
2. En agilidad tenemos interés porque el equipo técnico tenga una conciencia exacta sobre el esfuerzo que comporta hacer realidad cada una de las necesidades incorporadas al Product Backlog. I nunca el timming. El timming es una obsesión en la gestión tradicional de proyectos. En agilidad la obsesión es el valor. Por tanto, nunca preguntaremos a un técnico ni al equipo cuánto de tarda a resolver una necesidad concreta. Pero si preguntaremos qué esfuerzo comporta hacerla realidad.

Una vez tenemos clara la variable del esfuerzo sobre las necesidades. Podemos preguntar a los técnicos cuál es el timming para construir cada una de las tareas técnicas que hemos planificado. Esto tiene diversos beneficios, como son:

• Para conocer la dimensión de una tarea técnica. Y saber si esta es suficientemente atómica para poder ser construida sin riesgo. Debe existir un equilibrio en lo referente al timming de una tarea técnica. Tan negativo es tener tareas de minutos o pocas horas de duración, cómo tareas de muchas jornadas. Lo ideal en proyectos Scrum es que las tareas tengan una duración equivalente a una o dos jornadas de trabajo.
• En relación con el punto anterior, cuándo un técnico escoge una tarea técnica, gracias a esta estimación tiene una idea clara sobre el volumen de trabajo que será necesario abarcar. Y entonces podrá escoger más tareas para cubrir la jornada de trabajo.
• Tambien sirve para tener conciencia de lo que significa tener una historia de usuario estimada en cierto numero de story points (esfuerzo); y las tareas técnicas que proporcionan un timming a nivel atómico. Hay que decir en este punto que, creer que la suma de todas las tareas técnicas proporcionan el coste en timming de una historia de usuario, en mi opinión es una ilusión.
• Valorar tareas técnicas en timming puede dar KPIs e información volumétrica al Scrum Master para poder hacer un seguimiento del desempeño del equipo técnico.
• Por último, estimar las tareas técnicas en timming da perspectiva y experiencia al equipo técnico para que, en siguientes Sprints, se afine tanto la estimación en esfuerzo de las historias de usuario cómo la estimación fina en horas de las tareas técnicas. Un equipo que no adquiere el hábito de hacer estimaciones siempre cometerá errores a la hora de comprometerse con volúmenes de trabajo.

Con esto último podemos relacionar el concepto de Team Velocity. La Team Velocity es el volumen en Story Points que el equipo es capaz de comprometerse a hacer realidad a cada Sprint. A esto solo podemos llegar mediante la práctica, el conocimiento de las capacidades del equipo, la experiencia en los Sprints anteriores, y la comprensión al que el equipo llega sobre los conceptos de esfuerzo en historias de usuario, y timming en tareas técnicas.

La Team Velocity es la herramienta que permite a los equipos ágiles acertar con volúmenes de trabajo en los Sprint Plannings. Sin discusiones y en base a valores históricos justificables.

El Scrum Master ha de tener especial interés en disponer de esta información. Ya que la Team Velocity, las estimaciones en Story Points y los timmings dan información de valor para conocer el desempeño del equipo técnico. Pero tambien dará orientaciones muy acertadas sobre la complejidad del proyecto i su duración global en función del contenido del Product Backlog. Esto da respuestas con una base firme a la cuestión que siempre preocupa a los managers: Calendario y coste global del proyecto. Y podemos conocer esto sin planificaciones y sin presionar a los técnicos a dar timmings sobre necesidades. Es decir, sin traumas.

Algunos consejos para organizar una Sprint Planning

Algunos antipatrones típicos en la Sprint Planning

Descarega el esquema de la reunión de Sprint Planning

Descarga el esquema para imprimir aquí