¿Cómo hacer una estimación rápida de una gran pila de producto?

EstimacionAtPresentaciónRecientemente Juanma Gómez, João Barreiro (en la foto de la izquierda explicando el proceso) y Unai Roldán organizaron en Madriagil ) 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 de forma escalada.

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 a escala 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 escala 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:

dig

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.

EstimacionAtScaleEpicaDesglosada

Épica más importante( post-it azul) desglosada en Features (post-its verdes)

3. Elegir la feature más importante

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.

EstimacionAtScaleFeatureDesglosada

Feature ( post-it verde) desglosada en historias de usuario (post-its amarillos)

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.

EstimacionAtScaleCalibración.jpg

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.

EstimacionAtScaleBarajaCartas

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.

dav

Equipo estimando historia de usuario usando la técnica del Planning Poker con los números de la serie de Fibonacci 

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.

EstimacionAtScaleFeatureEstimada

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.

EstimacionAtScaleEpicasEstimadas

É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

sdrUna vez obtenida la estimación de las épicas, y en base a la métrica objetiva de velocidad del equipo o diferentes velocidades de los diferentes equipos, podemos proyectar hitos de fechas entrega, proyecciones que, aunque no precisas, nos llevan a un plan factible.

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.

Deseo que el post os sea de utilidad y espero vuestros comentarios

Saludos Cordiales,

Post escrito conjuntamente con Alexander Menzinsky

Anuncios

Mecanismos para evaluar historias de usuario

Uno de los temas que ha salido en las retrospectivas de algunos de los proyectos Scrum que se desarrollan en nuestra organización es la carencia de mecanismos que permitan evaluar las historias de usuario incluyendo los problemas a los que se ha enfrentado el equipo de desarrollo al implementar las historias, ya sean imprevistos o planificados y las soluciones y decisiones que se han tomado sobre las historias.

Pienso que el equipo de desarrollo junto al Product Owner son los que mejor pueden responder a estas preguntas. Los intercambios de información y los problemas a los que se ha enfrentado el equipo de desarrollo al implementar historias previas se pueden tratar en las reuniones de planificación del sprint y de refinamiento del backlog, donde se puede medir el éxito de las historias de usuario en cuanto a lo “fácil” o “difícil” que ha sido comunicarlas al equipo de desarrollo, y lo “fácil” o “difícil” que ha sido implementarlas, lo que culmina y se evidencia en la definición de los criterios de aceptación de las mismas.

Una vez que ha habido conversaciones al respecto a partir de las cuales se han identificado posibles problemas a resolver, elementos iniciales de mejora y se ha llegado a un mejor entendimiento de los problemas que se han presentado, se pueden organizar retrospectivas específicas sobre estos aspectos, con el propósito de profundizar en los primeros resultados obtenidos y, con base en lo que se quiera revisar, determinar quien debe asistir a cada reunión. Si se quiere tratar el tema del valor que aportan las historias y cómo lo hacen, entonces sería necesaria la participación del Product Owner, de los stakeholders y/o de los usuarios finales de las mismas, adicionalmente al equipo de desarrollo y al scrum master. Si se quiere evaluar aspectos y decisiones técnicas y de diseño entonces sería necesaria la participación de líderes técnicos, expertos en las tecnologías utilizadas y por supuesto el equipo de desarrollo y el Scrum Master.

Inspirándome en el blog de Alexander Menzinsky, una de las técnicas a utilizar para recoger las opiniones e ideas que vayan surgiendo en estas retrospectivas es la técnica de la estrella de mar de Patrick Kua. Esta técnica consiste en reflejar en un tablero visual, basado en una estructura de estrella de mar, lo que se quiere seguir haciendo, lo que hay que hacer más de alguna cosa, lo que hay que empezar a hacer, lo que hay que parar de hacer y lo que hay que hacer menos, pero en vez de hacerlo para el proyecto en general, hacer una estrella para cada elemento que se quiera estudiar en la reunión, tomando como base historias particulares que se quieran trabajar o aspectos técnicos y de diseño particulares que se quieran estudiar. Gráficamente sería algo como lo que se ve en la siguiente figura, donde los participantes irían colocando sus opiniones en cada una de las áreas, se abrirían discusiones al respecto, y al final se haría una priorización en cada área de los elementos que el grupo considere más importantes para comenzar a trabajar en los próximos sprints, siempre basados en el valor que estos aportan a los usuarios de las historias.

Tablero de la tecnica de la estrella de mar                                             Tablero de la técnica de la Estrella de Mar

Otra técnica que puede utilizarse en el caso de que se haya detectado algún problema y se quiera llegar a su causa raíz para tomar acciones al respecto  es el diagrama de espina de pescado o diagrama de Ishikawa. El detalle de cómo aplicar esta técnica lo podéis ver en el blog de Alexander Menzinsky, en su post ¿Cómo identificar de forma ágil posibles causas raíz de un problema?

Luego, al ir avanzando los sprints e ir aplicando las acciones correspondientes a los elementos seleccionados, se pueden hacer reuniones posteriores para ver que ha pasado, tomando como base las estrellas iniciales o las espinas de pescado iniciales y a partir de ellas ir evaluando si las acciones tomadas han sido exitosas o no, de manera tal de poder ir ajustando el rumbo, incorporar nuevos elementos, quitar los que ya no se consideren necesarios y seguir el ciclo virtuoso de mejora continua al priorizar, seleccionar e implementar elementos de cambio, mejora o de continuidad que el grupo acuerde.

Pero teniendo en cuenta en el viejo refrán que dice que es mejor prevenir que lamentar, antes de implementar cualquier historia de usuario es necesario asegurar que sean las mejores historias de usuario posibles, es decir, que sean unas historias bien escritas, con todas las de la ley, para tratar de disminuir los posibles problemas que se puedan presentar durante su implementación. Con respecto a esto es muy importante disponer de formas concretas, precisas y prácticas para evaluar si tenemos buenas historias antes de empezar a implementarlas.

En un curso de Scrum Manager que hice sobre historias de usuario, uno de los ejercicios consistía en evaluar la calidad de unas historias de usuario con base en:

  • Los criterios de Mike Cohn para escribir buenas historias de usuario (Como [rol del usuario], quiero [objetivo], para poder [beneficio])
  • El modelo INVEST, para evaluar la calidad de una historia de usuario viendo si cumple cada una de las características:
    • Inpedendent (Independiente)
    • Negotiable (Negociable)
    • Valuable (Valiosa para el usuario)
    • Estimable (Estimable)
    • Small (Pequeña)
    • Testeable (Comprobable)

Para hacerlo definí una forma práctica, sencilla y muy visual de evaluar las historias usando una hoja Excel donde se coloca la descripción de las historias y se refleja los resultados de la evaluación según los modelos mencionados previamente, obteniéndose una escala numérica que refleja el nivel de cumplimiento o no de cada una de las características de cada modelo y reflejando a nivel visual (por colores diferentes) si la historia en realidad es una historia de usuario o no y en caso de serlo, su nivel de calidad, tal y como lo podemos ver en la siguiente ilustración:

Imagen matriz evaluacion historias de usuarioEvaluación de historias de usuarios usando los criterios de Cohn y el modelo INVEST en una hoja Excel.

Pienso que esta puede ser una forma práctica de evaluar historias de usuario antes de llegar a implementarlas y con base en los resultados obtenidos, el Product Owner apoyado por el equipo de desarrollo y el Scrum Master, buscaría mejorar la calidad de las que obtengan las puntuaciones más bajas.

Adicionalmente a esta idea, otra forma de facilitar el proceso de escritura de historias de usuario de calidad es usando patrones y/o herramientas basadas en los modelos mencionados y en otros modelos. Una de las herramientas que me parece muy adecuada para apoyar la escritura de historias de usuario, su refinamiento y posterior gestión del backlog es la herramienta easyBacklog. Está disponible de manera online, es muy fácil de usar y gratis. Para saber más de esta herramienta y ver ejemplos de su uso pueden ver el post de Alexander Menzinsky ¿Qué tal easyBacklog como software para gestionar la pila de producto y los sprints?

Muchas gracias a Alexander Menzinsky por su colaboración y consejo durante la escritura de este post y a Scrum Manager por la imagen principal del mismo.