Planear un sprint

Artículo
06/10/2015

Por Mitch Lacey. Propietario de Mitch Lacey & Associates, Inc., una empresa de consultoría especializada en adopciones y mejoras de Agile y Scrum.

Enero de 2012.

Se aplica a

Application Lifecycle Management; Team Foundation Server

En este artículo:

Introducción
Previsiones frente a compromisos
¿En qué consiste la planeación de un sprint?
¿Cómo se cumple su propósito?
Problemas habituales
- Escenario: el equipo no se puede comprometer a todos los casos que ha solicitado el propietario del producto
- Escenario: el propietario del producto no acude a la reunión preparado
- Escenario: la primera parte supera el tiempo asignado
- Escenario: la segunda parte supera el tiempo asignado
- Escenario: el propietario del producto no está disponible
- Escenario: el equipo no dispone de los criterios de aceptación que necesita
- Escenario: el propietario del producto no sabe lo que significa terminar una tarea
- Escenario: el ScrumMaster o el propietario del producto realizan estimaciones o influyen en las estimaciones o el trabajo del equipo

No planeamos nada. Usamos Scrum y, por tanto, solo ejecutamos tareas.

Lo escucho constantemente. La gente piensa que Scrum y Agile significan que no hay que planear nada, hacer estimaciones, celebrar reuniones, ¡nada de nada! Esto no podría distar más de la realidad. Realizamos planeaciones en distintos niveles en un proyecto Agile: el plan diario o la reunión diaria, los planes semanales (sprint, iteración, trabajo pendiente), el plan de lanzamiento (trabajo pendiente del producto) y puede que otros.

En este artículo nos centraremos en la planeación de un sprint.

Previsiones frente a compromisos

En verano de 2011, Ken Schwaber y Jeff Sutherland revisaron su Guía de Scrum. Eliminaron un comportamiento de larga tradición en Scrum: el compromiso que suscribe el equipo con el propietario del producto y los clientes. El compromiso se reemplazó por la previsión. Afirman que los equipos pueden prever el trabajo, pero no comprometerse.

Aunque comprendo su razonamiento, prefiero el compromiso por los motivos siguientes:

El hecho de comprometerse a algo hace que el equipo adopte una mentalidad distinta que al realizar solo previsiones. Si un equipo realiza previsiones, se da a entender que no cumplir todos los objetivos que se ha marcado es un comportamiento aceptable. Aunque los equipos pueden sacar lecciones de sus previsiones y lograr que se reduzca la varianza en las estimaciones, me parece que los equipos que realizan previsiones tardan más en reducir la varianza que los equipos que suscriben compromisos.
Las previsiones o estimaciones son adecuadas para el trabajo pendiente del producto. Sin embargo, cuando los equipos trasladan casos del trabajo pendiente del producto al trabajo pendiente del sprint y los desglosan, agregan otro nivel de granularidad y pueden averiguar pequeños detalles que les permiten preguntarse "¿Nos podemos comprometer a esto?". Por el contrario, con las previsiones, los equipos se arriesgan a cierta pereza: "Solo tenemos que realizar las previsiones y no pasa nada si omitimos cosas, ya que podemos resolverlo más adelante".

En un divertido paralelismo, imagínese la reacción de su pareja si le dijera "Preveo que estaremos juntos diez años" en lugar de "Me comprometo a estar contigo".

En última instancia, Scrum se basa en el sentido común. Le sugiero que pruebe tanto el enfoque del compromiso como el de la previsión. Lo importante es aprender, no la terminología. Por tanto, sea inteligente, experimente con ambos y use el que le vaya mejor a usted, a su equipo y a su compañía.

¿En qué consiste la planeación de un sprint?

Una reunión de planeación del sprint se celebra para planear qué creará el equipo en el próximo sprint y cómo lo creará. Aunque nos referimos a ella como la reunión de planeación del sprint, se compone de dos partes muy distintas. La primera parte se centra en lo que se solicita al equipo que cree y a ella acuden tanto el propietario del producto como el equipo. La segunda parte se centra en la manera como el equipo planea crear la funcionalidad deseada. Aunque todo el equipo debe asistir a la segunda parte, la asistencia del propietario del producto es opcional. Si, por cualquier motivo, el propietario del producto no asiste a la segunda parte, debe estar disponible para responder a preguntas.

En la primera parte de la reunión de planeación del sprint, el propietario del producto tiene la oportunidad de describir el conjunto de casos deseados al equipo. Se trata de una sesión de inmersión en la parte del qué de los casos. El propietario del producto presenta los casos, muestra cómo interactúan los distintos elementos y recorre la interfaz. Además, es posible que revise los elementos de infraestructura o arquitectura. El objetivo es proporcionar suficiente información a los miembros del equipo para que puedan empezar a pensar en cómo crear la funcionalidad. El equipo hará una serie de preguntas para recopilar información para la reunión sobre el cómo, por ejemplo:

"¿Cuáles son los criterios de aceptación de todos estos casos?"
"¿Qué orígenes de datos cree que usamos?"
"¿Qué aspecto deberá tener la interfaz en este componente?"

Durante la segunda parte de la reunión de planeación del sprint, la atención del equipo se centra en crear el trabajo pendiente del sprint, que es la lista de casos y las tareas necesarias para completarlos durante el sprint. Para crear el trabajo pendiente, el equipo desglosa cada caso solicitado por el propietario del producto hasta el nivel de tarea; se asigna a cada tarea una estimación horaria. Al final de la segunda parte, el equipo decide cuáles son los casos que se puede comprometer a completar durante el sprint.

En conjunto, las dos partes de la reunión de planeación del sprint pueden durar entre dos y ocho horas. La regla de oro general que sigo es que cada parte debería durar una hora por cada semana del sprint. Es decir, si tenemos sprints de una semana, la reunión durará dos horas en total (una hora para la primera parte y una hora para la segunda parte). Por otra parte, si tenemos sprints de cuatro semanas, la reunión durará ocho horas en total (cuatro horas para la primera parte y cuatro horas para la segunda parte).

¿Cómo se cumple su propósito?

Siempre que el equipo salga de la reunión de planeación del sprint comprometido a completar una lista de casos, habrá cumplido el propósito de la planeación del sprint. No obstante, para llegar al punto en que cada uno de los miembros del equipo se sienta cómodo al suscribir ese compromiso, se requiere cierta planeación previa y facilitación.

El propietario del producto tiene una tarea durante la planeación del sprint: acudir a la reunión siendo capaz de describir un conjunto de casos deseados. El objetivo del equipo es comprender los casos desde el punto de vista del propietario del producto, para compartir su visión. El ScrumMaster se debe asegurar de que el equipo haga suficientes preguntas y capture todos los datos resultantes, incluidos los criterios de aceptación, los bocetos y las suposiciones. El ScrumMaster también debe comunicar al propietario del producto que es posible que el equipo tenga más preguntas después de empezar a desglosar las preguntas en tareas. Aunque el propietario del producto presenta casos cuyos totales de puntos corresponden aproximadamente a la velocidad histórica del equipo, el equipo decidirá en última instancia si puede, de hecho, hacerse cargo de todos los casos en un sprint dado, en función de los datos que obtenga durante la primera y la segunda parte de la reunión de planeación del sprint.

Después de que el equipo haya obtenido toda la información del propietario del producto, debe desglosar los casos en tareas y crear el trabajo pendiente del sprint, que captura todos los casos, notas, criterios de aceptación, tareas y estimaciones de un sprint concreto. Aunque hay muchas maneras de hacerlo, aplico el método siguiente, que aprovecha todas las ideas de los miembros del equipo y da voz a todos en la descomposición por tareas.

Pida al ScrumMaster o al facilitador de la reunión que lea un caso y pregunte "¿Todo el mundo lo entiende?". El equipo debería entenderlo, ya que acaba de pasar tiempo con el propietario del producto hablando del caso. Si alguien del equipo no lo entiende, dedique tiempo a volver a ver el caso y haga las preguntas necesarias al propietario del producto.
A continuación, pida a cada miembro del equipo que tome un taco de notas adhesivas. Pida a cada miembro del equipo que escriba una tarea en cada nota adhesiva y que la lance al centro de la mesa.
- Al lanzar cada nota adhesiva al centro de la mesa, el lanzador anuncia la tarea. Por tanto, si se ha escrito "actualizar procedimiento almacenado", se dirá en voz alta. Esto es importante, porque inspirará ideas y hará que otros digan "claro, y tenemos que actualizar el origen de datos". En ese momento, alguien escribirá en una nota adhesiva "actualizar origen de datos", lo dirá y la lanzará al centro. Esta actividad de lluvia de ideas sirve para sacar a la luz todas las tareas asociadas. No se preocupe por los duplicados en este momento. Para lanzar todas las notas adhesivas de tareas se suelen necesitar entre cinco y diez minutos por caso.
Cuando todas las notas adhesivas estén sobre la mesa, es hora de ordenarlas. Péguelas todas a la pared, tome cierta distancia y ya verá como hay muchas. Para empezar, identifique las duplicadas y colóquelas unas encima de otras. A continuación, busque tareas que parezca que tengan que ir juntas, bien porque son parecidas o bien porque dependen unas de otras. Por ejemplo, si dos notas adhesivas tienen una relación parecida, colóquelas juntas pero sepárelas un poco, como se muestra en la siguiente ilustración:

Si las tareas están tan relacionadas que son prácticamente idénticas, superpóngalas casi por completo, como se muestra a continuación:

Al ordenar las notas adhesivas, el equipo puede restringir la lista de tareas y visualizar las relaciones entre las tareas restantes.
Una vez ordenadas las tareas, es hora de hacer las estimaciones. Uso la técnica Planning Poker para las estimaciones de las tareas, con una diferencia: los números de las tarjetas representan horas en lugar de puntos. Lo hago porque las personas tienden a centrarse demasiado en detalles innecesarios en lo que respecta a las horas, en especial en tareas de gran envergadura. Este azoramiento tiene motivo. A menudo, las compañías usan la estimación para atacar al equipo. "Dijisteis que se necesitaban 8 horas y habéis tardado 12. ¿Qué ha pasado?" o "Dijisteis que se necesitaban 8 horas y solo habéis tardado 4. Estáis abultando las estimaciones".

Del mismo modo que las tarjetas ayudan a mantener la abstracción de los puntos del caso, el uso de tarjetas para la estimación de las tareas permite al equipo gozar de la libertad asociada con el hecho de disponer de un conjunto de números fijos para elegir y, al mismo tiempo, forzar al equipo a acabar tomando una decisión. También elimina acaloradas discusiones sobre si una tarea se debería estimar en 6, 6,5 o 7 horas.

Independientemente de la estimación final, recuerde que el equipo realiza la estimación y que solo debe usarla ese mismo equipo para aumentar su confianza y determinar si puede finalizar el trabajo que ha solicitado el propietario del producto basándose en la velocidad. Las estimaciones de las tareas no son métricas y no deben usarse como tales. No use nunca las estimaciones como un arma contra el equipo.
Ahora que ya se han estimado las tareas, el equipo debe averiguar si tiene capacidad para asumir más trabajo. Para ello, deberá conocer la capacidad del equipo, es decir, el total de horas de que dispone el equipo durante el sprint. Determinar la capacidad es fácil si tiene un equipo totalmente dedicado, pero se complica si el equipo está integrado por personas que trabajan a tiempo parcial en varios proyectos. Pida a cada persona que anote el número de horas que puede dedicar al proyecto al día (o el total por sprint). Sume todos los números para obtener el número total de horas disponibles para el equipo. Supongamos que la capacidad del equipo es de 200 horas. Si se estima que la suma de las tareas de un caso consumirá 30 horas, pregunte al equipo "¿Podemos asumir más trabajo?". En esta etapa temprana, la respuesta, obviamente, es afirmativa.

Como tiene más capacidad por ocupar, pase al siguiente caso y repita los pasos uno a cinco.

(Para obtener información sobre cómo realizar esta tarea con Team Foundation Server, vea Colaborar [redirigido]).

En algún momento tendrá dificultades a la hora de responder a la pregunta "¿Podemos asumir más trabajo?". Esto se debe a que está acercándose a la capacidad del equipo. A medida que sigue este proceso, piense que no le interesa llenar el sprint hasta su capacidad máxima. Si llena un vaso con agua hasta el borde, es muy probable que se derrame. Se puede decir lo mismo de los sprints. Si las horas estimadas consumen todo el tiempo disponible y se identifica una nueva tarea más tarde en el sprint, se desbordará al equipo. Debe dejar espacio para las tareas que puedan surgir.

Al pensar en el compromiso del sprint, ayuda tener en cuenta los datos retrospectivos de sprints anteriores. ¿El equipo tiene que incorporar más trabajo constantemente? Quizás podría comprometerse a más durante la planeación del sprint. ¿El equipo se ve constantemente incapaz de finalizar todo el trabajo de un sprint? Es posible que el equipo deba ser más conservador en sus compromisos hasta que haya eliminado la causa raíz de los sprints incompletos.

Una manera de asignar un número a la pregunta de "hasta qué punto hay que llenar el vaso" es pensar en el crecimiento del tamaño planeado. El crecimiento del tamaño planeado compara las horas reales invertidas con las estimaciones iniciales. Supongamos, por ejemplo, que el equipo tiene una capacidad de 200 horas disponibles. Se compromete a lo que considera serán 190 horas, basándose en las estimaciones. Al final del sprint, el equipo calcula que esos casos implicaron 240 horas de trabajo, lo que supuso un crecimiento del tamaño planeado del 20 %.

Un equipo que se encuentre con esta discrepancia debería dedicar cierto tiempo durante la retrospectiva a investigar los motivos:

¿Se descubren demasiadas tareas durante la ejecución que no se identificaron durante la planeación?
¿El equipo subestima las tareas basándose en sus habilidades actuales?
¿El equipo ha sobreestimado su capacidad?
Etcétera.

El equipo también debería pensar en el crecimiento del tamaño planeado durante la siguiente reunión de planeación del sprint al determinar si se puede comprometer con un caso. Volviendo al ejemplo, si el equipo sigue estimando una capacidad de 200 horas, debería restar el 20 % para compensar el crecimiento del tamaño planeado "esperado", que se basa en los datos históricos. Es decir, al menos para este sprint y para evitar desbordamientos, cuando el equipo llegue a las 160 horas, debería declarar que ha llegado a su capacidad.

Tener en cuenta el crecimiento del tamaño planeado es una manera de cuantificar el grado de ocupación del sprint. Sin embargo, debe entender que el objetivo no es coincidir exactamente con la capacidad. Más bien consiste en permitir al equipo que se sienta seguro a la hora de comprometerse a una cantidad apropiada de casos; una cifra que empuje al equipo sin sobrecargarlo. El crecimiento del tamaño planeado es una manera de determinar aproximadamente el grado de ocupación del siguiente sprint si todos los demás factores son iguales.

Cuando se hayan estimado todos los casos o los casos hayan consumido todo el tiempo, vuelva a hablar con el propietario del producto y comparta con él el trabajo pendiente del sprint que el equipo se ha comprometido a entregar. El sprint está a punto de empezar, ¡manos a la obra!

Problemas habituales

En todos los años que llevo asesorando a equipos para ayudarles a adoptar Scrum, he visto muchos problemas reiterados que impiden la planeación correcta del sprint. Aunque la planeación del sprint parece sencilla, los equipos que empiezan a trabajar con Scrum tienden a experimentar dificultades. Muchos de estos problemas y sus posibles soluciones se detallan en esta sección.

Escenario: el equipo no se puede comprometer a todos los casos que ha solicitado el propietario del producto

Esto puede suceder de vez en cuando. Siempre que el equipo pueda respaldar el compromiso con datos de los pasos cuatro y cinco indicados anteriormente en este tema, el propietario del producto debería darse por satisfecho. Se recomienda estar atento para asegurarse de que esta incapacidad de comprometerse no sea resultado de abultamientos o tareas de gran envergadura. El ScrumMaster debe cuestionar estimaciones que parezcan excesivamente conservadoras para asegurarse de que son precisas. El propietario del producto debe cuestionar cualquier tarea que tenga una estimación de dos dígitos. Si se estima que una tarea tardará más de dos días laborables en completarse, la tarea se debería desglosar en tareas más pequeñas y volver a estimarse. Esto es válido para todos los proyectos, pero es especialmente inquietante para equipos que llevan a cabo sprints de una o dos semanas.

Escenario: el propietario del producto no acude a la reunión preparado

Uno de los valores de Scrum es el respeto. Es una falta de respeto acudir a una reunión sin haberse preparado. ¿Qué puede hacer un equipo si el propietario del producto acude a la reunión sin la información que necesita el equipo? Aunque una opción es posponer la reunión hasta que el propietario del producto esté preparado, esto solo fomentará el mismo comportamiento. Por tanto, evítelo. Otra opción es cancelar el sprint. Aunque podría funcionar, es una medida extrema.

Opino que la mejor solución tiene dos vertientes. En primer lugar, el trabajo pendiente del producto debe tener cierto orden de prioridad. De este modo, si el propietario del producto no tiene un conjunto de casos concreto, el equipo y el propietario del producto podrán conversar sobre los casos en orden de prioridad hasta que consideren que han llegado a su capacidad máxima o la han superado. A continuación, como de costumbre, el equipo puede decidir cuál será el compromiso exacto durante la segunda parte de la reunión.

Tras la reunión, el ScrumMaster debe dedicarse a comprender los motivos por los que el propietario del producto no estaba preparado. Si el problema era la falta de implicación, el ScrumMaster puede explicar al propietario del producto la importancia de acudir a la reunión preparado con un conjunto de casos. Por otra parte, si el problema era que el propietario del producto no pudo prepararse, quizás porque el equipo no le ayudó con las actividades de limpieza, el ScrumMaster también deberá ayudar a resolver esos problemas.

Escenario: la primera parte supera el tiempo asignado

Otro de los valores es la concentración. Si la primera parte de la reunión supera el tiempo asignado, es síntoma de falta de concentración. A veces, el propietario del producto no está concentrado por falta de preparación, de clasificación por orden de prioridad o por intentar explicar demasiados casos. En otras ocasiones, la falta de concentración podría deberse a que el equipo hace descarrilar las conversaciones sobre el "qué" con datos concretos sobre el "cómo".

El ScrumMaster debe hacer avanzar la reunión insistiendo en que el propietario del producto posponga los casos que no se puedan explicar totalmente y que el equipo no converse sobre los detalles de la implementación durante la primera parte. Una solución sencilla para casos de falta de concentración en las conversaciones es el uso de un cronómetro o temporizador.

Escenario: la segunda parte supera el tiempo asignado

De nuevo, lo importante es la concentración. Si tiene un equipo que habla mucho, a veces basta con tener disciplina para limitar las conversaciones a fin de volver a encarrilar la reunión. Lleve un temporizador de cocina y mantenga la duración de las conversaciones en uno o dos minutos entre estimaciones de tareas. El objetivo es una cierta exactitud, no la precisión al 100 %.

En otras ocasiones, la falta de concentración durante la segunda parte es síntoma de la falta de limpieza del trabajo pendiente del producto durante la ejecución del sprint. En la etapa de limpieza, el equipo puede examinar los casos futuros y trabajar con el propietario del producto para agregar casos o picos para precisar direcciones de diseño o abordar preguntas sobre la arquitectura. Sin la limpieza habitual del trabajo pendiente del producto, la planeación del trabajo pendiente del sprint se hace difícil de manejar y muy complicada.

Escenario: el propietario del producto no está disponible

Si el propietario del producto no puede asistir a la reunión por cualquier motivo y no ha nombrado a otra persona para que lo represente, actúe como si el propietario del producto hubiera acudido a la reunión sin haberse preparado. Examine los elementos principales y comprométase a realizarlos de la mejor manera posible. Es posible que se sienta tentado a cambiar el horario de la reunión para adaptarse al calendario del propietario del producto. No lo haga. El cambio de horario de la reunión se adapta a las necesidades de una persona a costa de la mayoría. No merece la pena.

Escenario: el equipo no dispone de los criterios de aceptación que necesita

Siempre aconsejo a los equipos que hagan las siguientes preguntas al propietario del producto durante la primera parte: "¿Cuáles son los criterios de aceptación?" o "¿Qué tenemos que hacer para que acepte el trabajo?". Si esta información falta en la segunda parte, cuando el equipo determine las tareas, no tendrá ni idea de cómo conseguir cerrar el caso. Si el equipo tiene que hacer conjeturas en función de lo que escuchó en la primera parte, se arriesga a que el propietario del producto decida al final del sprint que el caso no está finalizado. Pregunte cuáles son los criterios de aceptación desde el principio de cada caso. Los ScrumMasters deben indicar a los propietarios del producto que proporcionen estos datos.

Escenario: el propietario del producto no sabe lo que significa terminar una tarea

Al igual que el equipo desea conocer los criterios de aceptación, el propietario del producto se merece una descripción actualizada de lo que quiere decir el equipo con "el caso está terminado". Esta lista de tareas terminadas se debe publicar de manera destacada y estar actualizada y disponible para el propietario del producto en todo momento. Una lista de tareas terminadas sin actualizar dificulta la planeación, porque no se sabe con certeza qué significará haber terminado una tarea. Asegúrese que la actualización de la lista de tareas terminadas forma parte de cada revisión o retrospectiva de sprint.

Escenario: el ScrumMaster o el propietario del producto realizan estimaciones o influyen en las estimaciones o el trabajo del equipo

El propietario del producto puede asistir a la segunda parte de la reunión, pero su rol en esta segunda parte se debe limitar a aclarar requisitos o abordar preguntas concretas. El propietario del producto no debe interferir nunca en la conversación del equipo sobre cómo implementar un caso y no tiene voz ni voto en la estimación de una tarea. El propietario del producto tiene que confiar en el equipo para que haga el trabajo.

Si el propietario del producto se sale de estas directrices, el ScrumMaster debe indicarle que su rol debe ser más apropiado. Si el propietario del producto se niega a aceptar un rol más pasivo, el ScrumMaster está autorizado a pedirle que abandone la reunión.

La planeación de sprints no tiene por qué suponer un desafío. A menudo es entretenida, además de ser un momento ideal para acercar a los integrantes del equipo Scrum al colaborar para responder a la pregunta "¿Qué compromisos podemos asumir?". Recuerde que si las reuniones duran demasiado, es posible la causa esté en la existencia de problemas de raíz. Si es el ScrumMaster, mantenga la concentración de la reunión asegurándose de que el propietario del producto y el equipo hagan la limpieza necesaria del trabajo pendiente del producto. Ayude al propietario del producto a acudir a la reunión preparado con la preparación de criterios de aceptación de los casos antes de la reunión. Por último, ayude a mantener la concentración del propietario del producto y el equipo en la tarea en cuestión para determinar qué compromisos pueden suscribir para el sprint.