martes, 2 de mayo de 2017

¿Cómo estimar en escalado una gran pila de producto?

João Barreiro presentando el workshop
Recientemente Juanma Gómez, João Barreiro y Unai Roldán organizaron en Madiagil un workshop sobre estimación en escalado #estimationatscale. El objetivo de este workshop fue experimentar practicando una manera rápida de hacer la estimación inicial de una pila de producto de un producto grande y de forma escalada.

Pasos a seguir para estimationatscale
Cuando pretendemos abordar un nuevo proyecto los requisitos iniciales nos llevan a grandes funcionalidades o módulos que en la pila de producto inicial se materializan como épicas. Ese será el punto de partida. La estrategia de estimationatscale es desglosar una épica en features, una de ellas en historias de usuario, estimar las historias en relativo, agregar estimaciones para obtener la estimación de la feature, estimar features en relativo respecto a esa feature de referencia, agregar estimaciones para obtener la estimación de la épica y finalmente estimar épicas en relativo.

La estimación en escalado debe de partir de una pila de épicas creada por un User Story Mapping hecho por el equipo de negocio. En el taller de estimación en escalado debe de estar presente el equipo de negocio y el equipo de desarrollo: de forma colaborativa desglosarán las épicas y features, y solo el equipo de desarrollo, quienes vayan a construir esas funcionalidades, estimarán el esfuerzo de los elementos en base a complejidad y tamaño.

Pasos a seguir para la estimación en escala:

1. Elegir la épica más importante

Partimos de una fila de épicas colocadas en un tablero o pared, en nuestro workshop estas están representadas por post-its de color azul. El Propietario del Producto elije la épica más importante, la que más valor de negocio tenga.

2. Desglosar épica

De forma colaborativa negocio y equipo de desarrollo desglosan la épica en features, grandes funcionalidades representadas por post-its de color verde en nuestro caso.
Épica más importante (post-it azul) desglosada en features (post-its verdes)
3. Elegir la feature más importante

Feature (post-it verde) desglosada en
historias de usuario (post-its amarillos)
De nuevo el Propietario del Producto elije en este caso la feature más importante, la que más valor de negocio tenga.

4. Desglosar feature

De forma colaborativa negocio y equipo de desarrollo desglosan la feature en historias de usuario, elementos de la pila lo suficientemente pequeñas para poder ser estimadas con las cartas de planning poker usuales, las que se basan en la serie de Fibonacci. Las historias de usuario están representadas por post-its de color amarillo en el workshop.

5. Calibrar escala

Para calibrar la escala el equipo elige una de las historias de usuario que represente la velocidad aproximada del equipo, el tamaño de esfuerzo realizable en un sprint, y le asigna el 21.
Historia de usuario que representa la velocidad estimada del
equipo calibrada con el número 21 de la serie de Fibonacci
6. Estimar historias de usuario

En base a la historia de de referencia 21 el equipo estima en relativo el resto de historias. Para el workshop UST Global nos ha proporcionado todos los participantes de barajas con la ¡serie de Fibonacci hasta el 987! Esta baraja nos posibilita la estimación relativa a los tres niveles de escalado de la pila de producto.
Cartas de planning poker para estimar en escalado proporcionadas por UST Global
En otro tablero o pared se crean post-its con la serie de Fibonacci, los mismos valores que las cartas de la baraja. En nuestro workshop estos se representaron sobre post-its rosas o naranjas (dependiendo del grupo). Una vez estimada una historia esta se coloca en el tablero o pared debajo del valor resultante.

7. Estimar features

Una vez estimadas todas las historias, se suman todas las estimaciones y la feature más importante se le asigna ese valor conviertiéndola en la feature de referencia para la estimación de features. A medida que se estiman features estas se colocan en el tablero o pared bajo el valor correspondiente.

Features estimadas (post-its de color verde) con valores de la serie
de Fibonacci a partir de la estimación de la feature de referencia
8. Estimar épicas

Del mismo modo que la estimación de features, se agregan las estimaciones de las features para el valor de la épica más importante y se sigue el mismo proceso de estimación.
Épicas estimadas (post-its de color azul) con valores de la serie
de Fibonacci a partir de la estimación de la épica de referencia
Una vez obtenida la estimación de las épicas, y en base a la métrica objetiva de velocidad del equipo o las diferentes velocidades de los diferentes equipos, podemos proyectar hitos de fechas de entrega, proyecciones que, aunque no precisas, nos llevan a un plan factible y más realista.

Recordemos que las estimaciones son aproximaciones que nos dan un valor útil para tomar decisiones acertadas, no son valoraciones estrictas y precisas para elaborar un plan milimetrado.

Agradecimientos a todos los participantes del workshop, ha sido un placer practicar #estimationatscale con todos vosotros, muchas gracias. :-D
Y este es el resultado final con las estimaciones a escala del workshop del equipo del que formé parte :-)
Mis agradecimientos a Gertrudis López por las fotos y su colaboración en el post, link al post en su blog "Agile: lo bueno, lo feo y lo malo"

4 comentarios:

  1. Hola Alexander, como bien dices esto es una aproximación. Con la experiencia y mejora continua del equipo o equipos, las estimaciones variarán. ¡ Gracias por el resúmen ! Un abrazo.

    ResponderEliminar
    Respuestas
    1. Me gusta decir que las estimaciones a nivel de épicas deben de ser un elemento de toma de decisión para una priorización correcta por parte de negocio. Luego estas se construyen más o menos cercanas a la estimación, lo importante no es cumplir estimaciones, lo importante es construir lo correcto en cada momento y con calidad.

      Gracias a ti por escribir :-)

      Alex

      Eliminar
  2. Gracias Alexander por el artículo.

    Precisamente estoy en el inicio de un gran proyecto, donde este ejercicio nos viene muy bien hacerlo, ya que el usuario final nos ha pedido una planificación inicial con fechas tentativas de las entregas parciales.

    Un saludo.
    Germán

    ResponderEliminar
    Respuestas
    1. Hola Germán,

      Me alegra mucho que el artículo sea de utilidad para vosotros.

      Quisiera resaltar que, bajo las premisas de este artículo, para que las fechas tentativas se cumplan con un margen de error de alrededor del 10-15% intentéis desarrollar equipos con una velocidad media de entre 20 y 25 puntos de historia. No os queda otra que medir la velocidad de los primeros sprints para obtener velocidades reales.

      Si vuestros equipos tuvieran una velocidad algo inferior, digamos entre 17 y 20, aconsejaría replantear las fechas, o contenido.

      Mucho éxito!!!

      Alex

      Eliminar