Planear un sprint

Artículo
02/19/2013

Por Mitch Lacey.Propietario, Mitch Lacey & Associates, Inc, firma consultora especializada en adopciones y mejoras de metodologías ágiles y de Scrum.

Enero de 2012.

La planeación del sprint no necesita ser un reto.Suele ser más divertido y una oportunidad para que todo el equipo Scrum cree lazos de amistad trabajando juntos para responder a la pregunta “¿Nos podemos comprometer?” En este artículo, los autores proporcionan ejemplos y estrategias para conservar planeación del Sprint centrada y que sea eficaz y ofrecer soluciones posibles detalladas a los problemas comunes a los que se enfrentan los equipos cuando planean un Sprint.

Se aplica a

Administración del ciclo de vida de la aplicación; Team Foundation Server

En este artículo:

Introduction
Pronóstico frente a compromiso
¿Qué es la planeación del sprint?
¿Cómo lo hacemos?
Problemas comunes
- Escenario: el equipo no puede confirmar todos los casos solicitados por el propietario del producto.
- Escenario: el propietario del producto no viene preparado.
- Escenario: la parte 1 supera el tiempo limitado disponible.
- Escenario: LA parte 2 supera el tiempo limitado disponible.
- Escenario: el propietario del producto no está disponible.
- Escenario: el equipo no tiene los criterios de aceptación que necesita.
- Escenario: el propietario del producto no sabe lo que significa finalizado.
- Escenario: el ScrumMaster o el propietario del producto está valorando/influenciando las estimaciones o el trabajo del equipo.
Conclusión

No planeamos.Hacemos Scrum, por lo que ejecutamos.

Oigo esto constantemente.La gente cree que Scrum y Agile implican ausencia de planeación, estimación, reuniones, ¡nada!Esto no puede estar más lejos la realidad.Planeamos diferentes niveles en un proyecto ágil: el plan diario o puesta en marcha, los planes semanales (sprint, o iteración, trabajo pendiente), el plan de lanzamiento (el trabajo pendiente del producto), etc.

Centrémonos en planear un Sprint.

Pronóstico frente a compromiso

En el verano de 2011, Ken Schwaber y Jeff Sutherland revisaron la Guía de Scrum.Aquí, quitaron un comportamiento establecido desde hace mucho tiempo conocido como Scrum, que es el compromiso que establece el equipo con el propietario del producto y los clientes.Se reemplazó la confirmación por pronóstico.Dicen que los equipos pueden pronosticar su trabajo, pero no comprometerse a hacerlo.

Si bien entiendo su lógica, yo prefiero el compromiso por las razones siguientes:

Cuando existe un compromiso, el equipo pasa a un estado mental distinto a simplemente lo relacionado con el pronóstico.Si un equipo hace un pronóstico, esto implica que si no se cumple todo lo que dicen que pueden hacer, es un comportamiento aceptable.Aunque los equipos pueden aprender de sus pronósticos, y al final tener menos varianza en sus estimaciones, he observado que los equipos que pronostican tardan más en reducir la varianza con respecto a los equipos que se comprometen.
Pronosticar, o estimar, es adecuado para el trabajo pendiente del producto.Sin embargo, cuando los equipos mueven casos del trabajo pendiente del producto al trabajo pendiente del Sprint y los desglosan, están agregando otro nivel de granularidad, al buscar pequeños detalles que les permitan preguntarse a sí mismos: “¿podemos confirmar a esto?”. Con los pronósticos se corre el riesgo de caer en un estado de pasividad por parte del equipo en lugar de decir: “solo debemos hacer un pronóstico, no pasa nada si perdemos material, ya veremos como lo arreglamos más adelante”.

Y en un tono más informal, imagine que dijo a su mujer, marido o pareja “Pronostico que estaremos juntos diez años” en comparación con “Me comprometo contigo” (esto queda mejor).

Finalmente, con el Scrum solo se requiere sentido común.Le sugiero que intente el enfoque del compromiso y el enfoque del pronóstico.Todo esto trata sobre aprendizaje, no sobre qué palabras se utilizan, por lo que debe ser inteligente, experimentar con ambos enfoques y utilizar el que sea mejor para usted, su equipo y su compañía.

¿Qué es la planeación del sprint?

Celebramos una reunión de planeación del sprint para planear qué compilará el equipo en el próximo sprint y cómo lo hará.Aunque nos refirmamos a ella como reunión de planeación del Sprint, consta realmente de dos partes muy diferentes.La Parte 1 se centra en lo que se pide al equipo que compile y asisten el propietario del producto y el equipo.La Parte 2 se centra en cómo el equipo compila la funcionalidad deseada.Aunque el equipo completo debe asistir a la Parte 2, la asistencia del propietario del producto es opcional.Si, por cualquier razón, el propietario del producto no asiste a la Parte 2, el propietario del producto debe permanecer disponible para las preguntas.

En la Parte 1 de la reunión de planeación del Sprint, el propietario del producto tiene la oportunidad de describir un conjunto deseado de casos para el equipo.Esto es una sesión de buceo de profundidad en la parte qué de los casos.El propietario del producto presenta los casos, muestra cómo interactúan las cosas y recorre la interfaz.Además pueden revisar la infraestructura o elementos arquitectónicos.El objetivo es rellenar las cabezas colectivas de los miembros del equipo con suficiente información para que puedan empezar a averiguar cómo compilar la funcionalidad.El equipo realizará diversas preguntas para recopilar información para la reunión cómo, preguntas como:

“¿Cuáles son los criterios de aceptación de todos estos casos?”
“¿Qué orígenes de datos cree que estamos usando?”
“¿Cómo debe ser la apariencia de la interfaz en este componente?”

Durante la Parte 2 de la reunión de planeación del Sprint, el equipo desvía la atención a compilar los trabajos pendientes del Sprint (la lista de casos y tareas necesarias a completar durante el Sprint).Para crear la lista de trabajo pendiente, el equipo desglosa hasta el nivel de tarea cada caso solicitado por el propietario del producto; se asigna a cada tarea una estimación de horas.Al final de la Parte 2, el equipo decide qué casos puede confirmar para su compleción durante el Sprint.

Juntas, las dos partes de la reunión de planeación del sprint pueden tardar entre dos y ocho horas.La norma general que utilizo es que cada parte debe durar una hora por cada semana de sprint.Esto significa que si se van a ejecutar sprints de una semana, la reunión durará un total de dos horas (una hora para la Parte 1 y una hora para la Parte 2).Si, por otro lado, ejecuto Sprints de cuatro semanas, la reunión se prolongará durante un total de ocho horas (cuatro horas para la Parte 1 y cuatro horas para la Parte 2).

¿Cómo lo hacemos?

Si el equipo deja la reunión de planeación del Sprint destinada a completar una lista de casos, el equipo habrá satisfecho el propósito de planeación del Sprint.Llevar al equipo al punto donde cada miembro del equipo se encuentre cómodo con ese compromiso, sin embargo, requiere un poco de proyección y simplificación.

El propietario del producto tiene un trabajo durante la planeación del sprint: ir a la reunión y ser capaz de describir un conjunto de casos deseados.El objetivo del equipo es entender los casos desde el punto de vista del propietario del producto, para compartir la visión del propietario del producto.El ScrumMaster debe asegurarse de que el equipo está haciendo suficientes preguntas y capturando todos los datos resultantes, incluyendo los criterios de aceptación, los bocetos y los supuestos.El ScrumMaster también debe comunicar al propietario del producto que el equipo puede tener más preguntas después de que comience a dividir las preguntas en tareas.Aunque el propietario del producto presente casos cuyos totales de punto se corresponden aproximadamente a la velocidad histórica del equipo, el equipo decidirá en última instancia si puede, de hecho, tomar todos los casos en un Sprint determinado según lo que vaya a aprender durante la Parte 1 y la Parte 2 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 un trabajo pendiente del Sprint, que capture todos los casos, notas, criterios de aceptación, tareas y estimaciones para un Sprint determinado.Aunque hay muchas maneras de hacerlo, yo uso el método siguiente, que aprovecha las ideas de todos los miembros del equipo y da a todo el mundo voz en la descomposición de las tareas.

Si el ScrumMaster o el organizador de la reunión leen un caso y pregunta “¿Lo han entendido todos?”, el equipo debe, como ha pasado un tiempo con el propietario del producto, debatirlo.Si alguien en el equipo no entiende, pasa algún tiempo volviendo a visitar el caso, realiza preguntas necesarias sobre el propietario del producto.
A continuación, pida a cada miembro del equipo que, en un bloc de notas adhesivas,escriban una única tarea en cada nota adhesiva y que la pongan en el centro de la mesa.
- Según se van poniendo las notas adhesivas en el centro de la mesa, la persona que la ponga anuncia la tarea.Así, si ha escrito “actualizar procedimiento almacenado”, lo dirá en voz alta.Esto es importante porque generará ideas y hará que los demás digan, “Ah sí, y tenemos que actualizar el origen de datos”. En ese momento, alguien se escribirá “actualizar origen de datos” en una nota adhesiva, lo dirá, y la lanzará en el centro de la mesa.Esta actividad de lluvia de ideas realmente funciona para sacar a la luz todas las tareas relacionadas.No se preocupe duplicados en este momento.Lanzar todas las notas adhesivas de las tareas requiere entre cinco y diez minutos por caso.
Cuando las notas adhesivas están todas en la mesa, es hora de clasificarlas.Póngalos todos en un muro, dé un paso atrás y observe: ¡hay cantidad de notas adhesivas!Comience por identificar los duplicados; solape las notas adhesivas que parezcan estar duplicadas.A continuación, busque las tareas que parecen ir juntas, porque son similares o porque dependen unas de otras.Por ejemplo, si dos notas adhesivas tienen una relación similar, póngalas juntas pero con separación entre ellas, como muestra la siguiente ilustración:

Si dos tareas están estrechamente relacionadas hasta el punto de ser prácticamente idénticas, superpóngalas casi totalmente, como se muestra a continuación:

Al ordenar las notas adhesivas, el equipo puede seleccionar la lista de tareas y visualizar las relaciones entre las que faltan.
Cuando las tareas están ordenadas, es hora de calcular.Uso la técnica de planeación de póquer para la estimación de la tarea, con una diferencia: los números de las cartas representan horas en lugar de puntos.Hago esto porque las personas suelen engancharse demasiado a detalles innecesarios con respecto a las horas, especialmente en las tareas de gran magnitud.Esta inquietud está bien fundamentada.Con demasiada frecuencia, las compañías utilizan la estimación como un bastón para golpear al equipo.“Dijo que tardaría 8 horas y tardó 12.¿Qué es lo que pasa?” o “Dijiste que tardaría 8 horas y tardó solo 4.Estás calculando las estimaciones con demasiado margen.”

De la misma manera que las cartas ayudan a tener una visión abstracta de las estimaciones de los puntos de casos, si se usan las cartas para la estimación de la tarea permite al equipo disponer de la libertad que conlleva la posesión de un conjunto de números fijos a elegir mientras los fuerza a tomar en última instancia una decisión.También elimina los debates acalorados sobre si una tarea debe estimarse en 6 horas o en 6,5 horas o en 7 horas.

Sea cual sea la estimación final, recuerde que la estimación la realiza el equipo y está pensada para ser utilizada solo por este para ayudar a aumentar su confianza y determinar si puede realizar el trabajo solicitado por el propietario del producto basándose en la velocidad.Las estimaciones de la tarea no son métricas y no deben usarse como tal.Nunca use las estimaciones como arma contra el equipo.
Ahora que se han estimado las tareas, el equipo debe determinar si tiene la capacidad de asumir más trabajo.Para ello, deberá conocer la capacidad del equipo, el total de horas que tiene disponibles el equipo durante el sprint.Determinar la capacidad es fácil si tiene un equipo plenamente dedicado pero se hace más difícil si tiene un equipo compuesto de las personas a tiempo parcial que se dividen en varios proyectos.Pida a todos que anoten el número de horas que cada pueden trabajar en el proyecto por día (o el total por el Sprint).Agregue todos los números a la vez para obtener el número total de horas disponibles para el equipo.Supongamos que la capacidad del equipo resulta ser 200 horas.Si la suma de tareas para un caso se estima que pueda consumir 30 horas, pregunte al equipo, “¿Podemos asumir más trabajo?”. En esta fase inicial, la respuesta será obviamente que sí.

Dado que tiene mayor capacidad de relleno, vaya al siguiente caso y repita los pasos del uno al cinco.

(Para obtener información sobre cómo realizar esta tarea mediante Team Foundation Server, vea Iteraciones y planeación de Agile.)

En algún momento, tendrá momentos difíciles para responder a la pregunta, “¿podemos asumir más trabajo?” Esto se debe a que se aproxima al límite de capacidad del equipo.Cuando se trabaja con este proceso, considere que no desea rellenar el Sprint para la capacidad.Si rellena un vaso con agua hasta el borde, es muy probable que se derrame.Lo mismo sucede con los sprint.Si las horas estimadas usan todo el tiempo disponible y se identifica una nueva tarea se identifica más adelante en el Sprint, habrá una sobrecarga.Debe dejar margen para las tareas emergentes.

Cuando se considera el compromiso del sprint, es útil considerar datos retrospectivos de sprints anteriores.¿Tiene el equipo que aceptar sistemáticamente más trabajo?Quizás el equipo podría comprometerse a más durante la planeación del Sprint.¿El equipo es sistemáticamente incapaz de finalizar todo el trabajo de un Sprint?Puede que el equipo deba ser más conservador con sus compromisos hasta que haya resuelto la causa principal de los sprints incompletos.

Una manera de numerar la cuestión de “¿Cómo está de lleno el vaso?” es considerar el crecimiento del tamaño del plan.Planear el crecimiento del tamaño mide las horas reales invertidas en comparación con las estimaciones iniciales.Supongamos, por ejemplo, que el equipo tiene una capacidad de 200 horas disponibles.El equipo se compromete a lo que cree que serán 190 horas, en función de las estimaciones.Al final del Sprint, el equipo calcula que esos casos conllevaban 240 horas reales del trabajo, lo que da como resultado un crecimiento del plan del 20%.

Un equipo que encuentre esta diferencia debe destinar algún tiempo durante la reunión retrospectiva investigando las razones:

¿Se han detectado demasiadas tareas durante la ejecución que no se identificaron durante la planeación?
¿Subestima el equipo sus tareas basándose en sus conocimientos actuales?
¿Sobrestimó el equipo su capacidad?
Y así sucesivamente.

El equipo también debe considerar el crecimiento del tamaño del plan durante la siguiente reunión de planeación del sprint al determinar si puede confirmar un caso.Volviendo a nuestro ejemplo, si aún el equipo estima una capacidad de 200 horas, el equipo debe restar un 20% del máximo para compensar el crecimiento del tamaño del plan “esperado” según los datos históricos.Es decir, por lo menos este Sprint, para evitar sobrecargas, cuando el equipo llegue a 160 horas, debe declararse a sí mismo en capacidad máxima.

Considerando el crecimiento del tamaño del plan es una manera cuantificar lo lleno que debería estar el Sprint.Tenga en cuenta, sin embargo, que el objetivo no es aprovechar exactamente toda la capacidad.En realidad, el objetivo es que el equipo se sienta seguro al aceptar un número adecuado de casos, uno que dinamice al equipo sin sobrecargarlo.Planear el crecimiento del tamaño del plan es una manera de determinar aproximadamente lo lleno que debe estar el siguiente Sprint, si el resto de los factores no cambian.

Cuando se estimen todos los casos o estos consuman todo el tiempo, regrese con el propietario del producto y comparta el trabajo pendiente del sprint que el equipo se ha comprometido a entregar.El sprint comienza ahora, así que, ¡a trabajar!

Problemas comunes

En mis años asesorando a equipos para ayudarles a adoptar Scrum, he visto muchos de los mismos problemas que impiden la planeación correcta del Sprint.Aunque la planeación del Sprint parezca sencilla, los equipos que acaban de empezar con Scrum suelen pasarlo mal.Muchos de estos problemas y sus soluciones posibles se detallan en esta sección.

Escenario: el equipo no puede confirmar todos los casos solicitados por el propietario del producto.

Debe esperar que esto suceda de vez en cuando.Mientras el equipo pueda respaldar los compromisos con los datos de los pasos cuatro y cinco descritos anteriormente en este tema, el propietario del producto se quedará satisfecho.Deseará estar atento para asegurarse de que esta falta de compromiso no es el resultado de la sobreestimación de tareas o de tareas grandes.El ScrumMaster debe enfrentarse a lo que parecen ser estimaciones demasiado conservadoras para asegurarse de que son precisas.El propietario del producto debe cuestionar cualquier tarea que tenga una estimación de dos dígitos.Las tareas que se calcule que puedan llevar más tiempo de dos días laborables deben desglosarse en otras más pequeñas y ser recalculadas.Esto se aplica a todos los proyectos, pero es especialmente preocupante para los equipos que realizan sprints de una o dos semanas.

Escenario: el propietario del producto no viene preparado.

Se respeta un valor de Scrum.Es irrespetuoso llegar una reunión sin preparar.Entonces, ¿qué debe hacer un equipo si el propietario del producto aparece sin la información que necesita el equipo?Aunque una opción sea aplazar la reunión hasta que el propietario del producto esté listo, si se hace fomentaría este tipo de comportamiento: evítelo.Otra opción es cancelar el Sprint.Aunque esto pueda funcionar, es extremado.

Creo que la mejor solución tiene dos aspectos.Primero, el trabajo pendiente del producto debería estar clasificado según algún tipo de prioridad, por lo que si el propietario del producto no tiene un determinado conjunto de casos, el equipo y el propietario del producto pueden simplemente debatir los casos en el orden de prioridad hasta alcanzar un punto donde crean que han llegado o superan su capacidad máxima.El equipo puede decidir compromiso exacto durante la Parte 2 de la reunión, como de costumbre.

Después de la reunión, el ScrumMaster debería funcionar para saber por qué el propietario del producto no esta preparado.Si el problema era una falta de compromiso, el ScrumMaster puede indicar al propietario del producto la importancia de acudir preparado a la reunión con un conjunto de casos.Si, por otro lado, el problema es que el propietario del producto no pudo prepararse, quizás porque el equipo no pudo ayudarle con la preparación, el ScrumMaster debe ayudar a solucionar estos problemas también.

Escenario: la parte 1 supera el tiempo limitado disponible.

Otro valor es el foco.Si se está terminando la Parte 1 de la reunión, indica una falta de foco.A veces, el propietario del producto no está centrado debido a falta de preparación o de prioridades, o intenta explicar demasiados casos.Otras veces, la falta de foco podría proceder de que el equipo habla de procedimientos sin identificar los objetivos.

El ScrumMaster debe ayudar a que avancen los temas insistiendo en que el propietario del producto posponga cualquier asunto que no pueda explicarse totalmente y en que el equipo debe dejar las discusiones de implementación detalladas fuera de la Parte 1.Una corrección simple para un debate que no está encaminado es usar un cronómetro o un temporizador.

Escenario: LA parte 2 supera el tiempo limitado disponible.

De nuevo, el foco.Si tiene un equipo que habla mucho, a veces un poco de disciplina para limitar las conversaciones es todo lo que se necesita para volver a la buena dirección de la reunión.Traiga un cronómetro y mantenga conversaciones de un minuto o dos entre las valoraciones de la tarea.El objetivo es la exactitud, no la precisión al 100%.

Otras veces, la falta de foco durante la Parte 2 es sintomática de una falta de trabajo pendiente del producto en preparación durante la ejecución del Sprint.La preparación es el momento en que el equipo puede buscar casos para el futuro y trabajar futuros con el propietario del producto para agregar casos o picos para precisar direcciones de diseño o abordar preguntas sobre la arquitectura.Si no se realiza con regularidad la preparación del trabajo pendiente del producto, el planeamiento del trabajo pendiente del sprint se vuelve pesado y doloroso.

Escenario: el propietario del producto no está disponible.

Si el propietario del producto no puede asistir a la reunión por cualquier razón y no ha determinado un proxy, actúe como si el propietario del producto hubiese venido a la reunión sin preparar.Trabaje con los elementos superiores y comprométase con ellos lo mejor que pueda.Puede verse tentado de cambiar la hora de la reunión para adaptarla a la programación del propietario del producto.Evitar.Cambiar la hora de la reunión satisface a una persona a costa de perjudicar a los demás.No merece la pena.

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

Aconsejo siempre a los equipos preguntar al propietario del producto durante la Parte 1, “¿cuáles son los criterios de aceptación para esto?” o “¿qué debemos hacer para usted acepte el trabajo?”. Si esto falta en la Parte 2, cuando el equipo está determinando las tareas, el equipo no tendrá idea alguna de cómo cerrar el caso.Si el equipo tiene que adivinar, basándose en lo que oyó en la Parte 1, el equipo corre el riesgo de que el propietario del producto decida al final del Sprint que el caso no ha finalizado.Pida criterios de aceptación desde el principio para cada caso.Expertos en Scrum: adiestren a los propietarios del producto para proporcionar estos datos.

Escenario: el propietario del producto no sabe lo que significa finalizado.

Al igual que el equipo desea criterios de aceptación, el propietario del producto merece una descripción actualizada de lo que quiere decir el equipo con "el caso está finalizado". Esta lista de tareas realizadas debe publicarse visiblemente, estar actualizada y disponible en todo momento para el propietario del producto.Una lista de tareas realizadas no actualizada dificulta planear porque no hay conocimiento común del aspecto que tendrán esas tareas realizadas.Asegúrese de que la actualización de la lista de tareas realizadas es una parte integrante de cada revisión o retrospectiva de Sprints.

Escenario: el ScrumMaster o el propietario del producto está valorando/influenciando las estimaciones o el trabajo del equipo.

El propietario del producto es bienvenido en la Parte 2 de la reunión, pero su rol aquí debe limitarse a clarificar un requisito o responder una pregunta específica.El propietario del producto nunca debe interferir en el debate del equipo acerca de cómo implementar un caso y no tiene voz en la estimación de una tarea.El propietario del producto debe confiar en el equipo para realizar el trabajo.

Si el propietario del producto no cumpliera estas directrices, el ScrumMaster debe enfocar al propietario del producto hacia un rol más adecuado.Si el propietario del producto rechaza aceptar un rol más pasivo, el ScrumMaster tiene autoridad para pedir al propietario del producto que se vaya.

La planeación del sprint no necesita ser un reto.Suele ser más divertido y una oportunidad para que todo el equipo de Scrum cree lazos de amistad trabajando juntos para responder a la pregunta “¿Nos podemos comprometer?”. Recuerde que, si observa que las reuniones se prolongan demasiado, los problemas de la causa principal probablemente provoquen esto.Si es el ScrumMaster, mantenga la reunión centrada asegurándose de que el propietario del producto y el equipo preparan el trabajo pendiente del producto.Ayude al propietario del producto a acudir preparado con los criterios de aceptación del caso listos antes de la reunión.Finalmente, ayudar a que el propietario del producto y el equipo estén centrados en la tarea del momento, determinando en qué se pueden comprometer para el Sprint.