¿Los requisitos muy detallados dan mejores resultados que una buena visión y entendimiento de las necesidades?

Este es un ejercicio del curso CSPO de

Sabine, una CST con la que he hecho co-training, me ha explicado un ejercicio que es genial para diferenciar los resultados de la construcción a través de historias de usuario versus requisitos clásicos detallados. Recordemos que la diferencia radica en que a través de una historia de usuario somos capaces de empatizar y ponernos en el lugar del usuario, y por tanto obtener un resultado mucho más acertado y que redundará en una mejor solución. El ejercicio consiste en ambos casos en dibujar una hermosa pradera.

Equipos que se basan en la visión a través de una historia de usuario

"Dibujad una bonita pradera según la siguiente historia de usuario:

Como huésped de un hotel rural
quiero vistas a una bonita pradera verde salpicada de flores rojas y azules, algunas vacas y pájaros y bajo un sol radiante
para poder disfrutar de mi estancia y desconectar del día a día"

Resultado de los dibujos basados en una historia de usuario

Equipos que se basan en la misión explicitada a través de unos requisitos detallados

"Dibujad una bonita pradera verde con:

• 10 flores azules de 5 pétalos cada una
• 5 flores azules de 6 pétalos cada una
• 13 flores rojas de 6 pétalos cada una
• 2 vacas con 3 manchas negras
• 1 vaca con 5 manchas negras
• 2 vacas con 4 manchas negras
• 2 pájaros en la esquina superior izquierda
• 3 pájaros en medio de la imagen
• Un sol en la esquina superior derecha con 5 rayos de sol"

Resultado de los dibujos basados en una requisitos clásicos detallados

Los equipos con los requisitos detallados probablemente no acaben, se verá claramente que estos se han focalizado en los detalles y han perdido la perspectiva de una visión global de una pradera. Podemos observar en las imágenes anteriores que los elementos no integran, hay o bien microvacas o macroflores por ejemplo...

Nos pueden gustar más unos dibujos que otros, indistintamente de cómo el equipo recibió la especificación, podemos verlo en los post-its verdes que representan los votos individuales de qué dibujo ha gustado más. Pero si nos preguntamos por el contexto del usuario y qué es lo que necesita y para qué, si nos preguntamos qué dibujos son más adecuados para relajarnos y desconectar del día a día, es fácil coincidir en que en este punto hay una gran diferencia.

Pasos a seguir para el ejercicio

• Formar equipos de 4 personas
• Cada equipo recibe una hoja de rotafolios y 4 rotuladores cubriendo los 4 colores: azul, negro, rojo y verde
• Cada equipo recibe una de las dos formas de requisitos de forma aleatoria, los equipos no saben que hay dos instrucciones diferentes
• Dibujar de forma colaborativa una pradera según los requisitos recibidos
• 30 segundos para planificación de sprint
• Sprint de 90 segundos para dibujar
• Al finalizar enganchar el rotafolio en la pared
• Iniciar una conversación con la pregunta: ¿Qué diferencias encontráis entre los diferentes dibujos? - entonces es cuando suelen darse cuenta de que han recibido instrucciones diferentes

Mis agradecimientos a la clase de mayo de 2017 que han hecho estos dibujos espectaculares :-)

¿Las historias técnicas tienen valor de negocio?

Todo aquello que tiene valor de negocio hace que las
empresas obtengan beneficios - Cortesía de Pixabay

Nacho, un asistente a uno de mis cursos, se extrañaba de que una historia técnica, como la instalación de una base de datos Oracle, no tuviera valor de negocio. Exclamaba: ¡Debe de tener valor para nuestro cliente, sino no puede funcionar nada!

Suelo definir que algo tiene valor de negocio cuando el cliente está dispuesto a pagar por ello. Nuestros clientes no están interesados en pagar por una base de datos de Oracle, lo hacen porque sino no podemos construir las funcionalidades que luego si tienen valor de negocio para ellos. Lo que tiene valor de negocio es aquello que resuelve problemas a nuestro cliente.

Thomas Wallet lo define en su post 8 otras maneras de definir el Valor de Negocio como: "El concepto de Valor de Negocio (Business Value) representa el beneficio al cual accede una empresa/institución/grupo de usuarios cuando se disponibiliza una nueva funcionalidad de software para su uso productivo". Según esta definición es fácil ver que toda historia técnica, como una base de datos Oracle, una granja de servidores o la resolución de deuda técnica no genera beneficios desde el punto de vista de negocio.

Una forma aún muy clara para identificar si algo tiene valor de negocio es a través de la forma más conocida para medirlo, la fórmula para encontrar la utilidad o ganancia que puede generar:

Utilidad = Ingresos Totales – Costos Totales

Las historias de usuario se convierten en funcionalidades que mecanizan el core-business del cliente y por tanto permiten a la compañía tener ingresos. Éstas consumen los resultados y lo que construyen las historias técnicas, historias que representan costos para la compañía, algunos de ellos fijos.

Bajo esta perspectiva la priorización de la pila de producto por valor de negocio flaquea, las historias técnicas no se pueden priorizar de la misma manera que el resto. La mejor forma de priorización es basándose en el coste de la demora. Todos los elementos de la pila de producto tienen coste de la demora, en las historias de usuario representa lo que dejamos de ganar al no ser competitivos y no permitir a la compañía captar oportunidades de negocio que emerjan en el mercado. En las historias técnicas representa lo que dejamos de ganar porque las historias de usuario que las consumen no pueden funcionar y generar beneficios.

Mis agradecimientos a Nacho, fue un debate muy interesante :-)

¿Por qué la mejora continua es tan importante en Agilidad?

El ser humano siempre ha aprendido de forma empírica a base de prueba y error, hecho que ha llevado a la humanidad al patrón dialéctico basado en tesis, antítesis y síntesis para la adquisición de conocimiento y su evolución:

Patrón Dialéctico: tesis, antítesis y síntesis - cortesía de Scrum Manager

La puesta en funcionamiento de nuevas técnicas, procesos o modelos genera sus propias antítesis al revelarse las debilidades, contradicciones y puntos de mejora, y el enfrentamiento de ambos conduce hacia una síntesis, que pasará a ser una nueva tesis, cuyo posterior uso producirá su antítesis, desarrollando a través de este patrón dialéctico una espiral de evolución continua del conocimiento.

No hay métodos, prácticas o modelos de trabajo que nos ayuden con solvencia durante mucho tiempo, sino conocimiento en evolución. El conocimiento profesional evoluciona de forma continua porque la realidad en la que se aplica está en permanente movimiento, y también porque la mejora siempre es posible.

Tampoco hay productos estáticos que no evolucionen, si fuera el caso el producto probablemente estaría obsoleto. El software en forma de producto se materializa en herramientas que mecanizan el core-business de nuestros clientes, por tanto el software debe de evolucionar con la misma adaptabilidad que exige el mercado de nuestro cliente. Bajo esta perspectiva cuanto más evolucione el software más competitivo y más cuota de mercado tendrá nuestro cliente, por tanto más beneficios tendrá.

Recordemos que la Agilidad y Scrum no son para mejorar la construcción de funcionalidades, sino para mejorar la adaptabilidad y la entrega de valor a nuestros clientes. No se trata de cumplir con objetivos o de cumplir estimaciones, en una cultura clásica celebramos y consideramos un éxito si cumplimos, en Agilidad se trata de ser mejores cada día y llegar mucho mas lejos, mucho más allá de nuestros objetivos iniciales.

Para ello la Agilidad se dota de la inspección y adaptación a través del ciclo de mejora continua de Demming, y lo hace en dos frentes, en la forma en que trabajamos y en el producto. En definitiva nos convertimos en una organización con aprendizaje continuo del que todos debemos de participar.

La mejora en adaptabilidad y en entrega de valor, propias de Scrum y Agilidad,

implica la mejora continua a todos los niveles, la mejora continua es el core de la Agilidad

Para la mejora continua en las formas de trabajar:

• Realizar retrospectivas de forma periódica en todas las áreas de la compañía.
• Realizar talleres de resolución colaborativa de problemas ante todo impedimento organizacional.

Para la mejora continua del producto:

• Construir de forma incremental con ciclos de aprendizaje rápidos e integrados.
• Cada incremento puede ser evaluado por constructores y clientes.
• Los puntos de integración convierten incertidumbre en conocimiento (en algunos puntos de integración podemos obtener prototipos que se pueden probar en el mercado y tomar feedback).
• Los puntos de integración nos permiten pivotar y mantenemos en la dirección adecuada para la solución, tanto en viabilidad técnica como de solución para negocio.
• Los puntos de integración deben de estar a todos los niveles, desde los equipos, a los equipos de equipos y al resto de la compañía.

Mis agradecimientos a Juan Palacio y Scrum Manager al que debo el patrón dialéctico de este post

¿Cuáles son los elementos del marco de Scrum?

Estos días estuve acompañando a la CST Sabine Canditt como co-trainer, y esta hizo un dibujo tan espectacular del marco de Scrum que quiero compartirlo. La técnica de dibujo se llama Bikablo®, un método de visualización y la facilitación nuevo para hacer que el contenido y el proceso sean visibles en tiempo real.

El marco de Scrum - Thanks to Sabine

Roles

• PO (Propietario del Producto)
• SM (Scrum Master)
• Dev team (Equipo de desarrollo)

Artefactos

• Pila de Producto (alimentada por la Visión del Producto)
• Pila de Sprint
• Incremento

Eventos

• Sprint
• Planificación de sprint
• Daily Scrum
• Revisión de sprint
• Retrospectiva
• *Refinamiento de PBI's (product backlog items), evento que no es del marco pero usual en todas las implementaciones de Scrum

Thanks to Sabine for her spectacular drawing

¿Los Scrum Masters son un rol temporal en las organizaciones?

Post-it en :-) de una retrospectiva

Una de las responsabilidades de un Scrum Master es hacerse prescindible para el equipo cuanto antes, eso significa que habrá conseguido llevar al equipo a ser ágil. Un equipo ágil habrá interiorizado la mentalidad ágil, será autoorganizado y con la suficiente madurez para no necesitar de un Scrum Master que le guíe y entrene en Scrum.

A la derecha un post-it de una retrospectiva en la que el equipo colocó "Todo fluye sin SM" en la columna de las cosas que le gustaba. Estaban diciéndome que había hecho un buen trabajo y que todo fluía ya por su propio pie. Fue un gran día, fue el día en que había terminado mi trabajo de desarrollo en Agilidad de ese equipo.

Bajo esta perspectiva ¿cual es el futuro del Scrum Master? ¿Una vez los equipos fluyen por si mismo el Scrum Master ya no tiene cabida en la organización?

El Scrum Master como agente del cambio
Thanks Sabine

¡Más bien todo lo contrario! En fases tempranas el Scrum Master empieza con un par de equipos, primero en la preparación del entorno en el sprint 0, y luego en el crecimiento y desarrollo de cada uno de ellos. A medida que estos maduran va escalando de forma paulatina y va incorporando a Scrum a los demás equipos.

A medida que incorpora Scrum a nuevos equipos se plantean nuevos retos cuya solución hay que facilitar. Para que los equipos sean ágiles y efectivos han estar alineados y sincronizados, lo que requiere la facilitación de eventos para grandes grupos. En este tipo de eventos la facilitación siempre será imprescindible, por su tamaño y complejidad no puede fluir sin un coach o un Scrum Master.

La resolución de dependencias y la detección y resolución de riesgos son temas complejos que la Agilidad resuelve de forma compleja; la mejor forma de resolución es aquella en que participan todos los equipos a través de un evento para grandes grupos, sacando así provecho a la diversidad de perspectivas y opiniones de decenas o cientos de cabezas inteligentes que juntas pueden encontrar soluciones excelentes.

El rol del Scrum Master se convierte en un agente del cambio a nivel de toda la organización, personas que actúan como catalizadores de la transformación ágil centrándose en la eficacia, la mejora continua y el desarrollo de la organización:

• Liderando y entrenando desde los equipos a los directivos en su adopción de Scrum
• Planificando la adopción e implementaciones de Scrum en la compañía
• Ayudando a los empleados a comprender y a aplicar Scrum en el desarrollo de productos
• Apoyando a los Propietarios del Producto y a los equipos de negocio
• Apoyando en la contratación ágil de proyectos y equipos
• Trabajando con otros Scrum Masters para aumentar la efectividad de la aplicación de Scrum en la organización
• Apoyando en la presupuestación ágil

Distribución de la ocupación del Scrum Master en una
organización - Thanks Sabine :-)

Como muestra el gráfico de la distribución de la ocupación de un Scrum Master, su dedicación a la organización crece con el tiempo. Me gusta compararlo con el aceite de un motor, el Scrum Master o equipo de Scrum Masters y coaches son el aceite que hace que el motor del core-business de la compañía ruede de la forma más eficiente posible. Sin esa labor de coaching no hay mejora continua y las diferentes partes de la compañía pueden acabar divergiendo y ralentizando el flujo.

Seguido veamos el extracto de la Scrum Guide de como ha de actuar el Scrum Master en estos tres frentes.

---

El Scrum Master da servicio al Propietario del Producto de varias formas, incluyendo:

• Encontrar técnicas para gestionar la pila de producto de manera efectiva;
• Ayudar al equipo Scrum a entender la necesidad de contar con elementos de pila de producto claros y concisos;
• Entender la planificación del producto en un entorno empírico;
• Asegurar que el Propietario del Producto conozca cómo ordenar la pila de producto para maximizar el valor;
• Entender y practicar la Agilidad; y,
• Facilitar los eventos de Scrum según se requiera o necesite.

El Scrum Master da servicio al equipo de desarrollo de varias formas, incluyendo:

• Guiar al equipo de desarrollo en ser autoorganizado y multifuncional;
• Ayudar al equipo de desarrollo a crear productos de alto valor;
• Eliminar impedimentos para el progreso del equipo de desarrollo;
• Facilitar los eventos de Scrum según se requiera o necesite; y,
• Guiar al equipo de desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.

El Scrum Master da servicio a la organización de varias formas, incluyendo:

• Liderar y guiar a la organización en la adopción de Scrum;
• Planificar las implementaciones de Scrum en la organización;
• Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto;
• Motivar cambios que incrementen la productividad del equipo Scrum; y,
• Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de en la organización.

---

Por tanto, los que seáis y apostéis por el oficio de Scrum Master, tened por seguro que tendréis un largo recorrido. :-D

Thanks to Sabine Canditt for her teachings and the spectacular drawings

¿No sería marketing un ámbito ideal para la aplicación de Scrum?

El marketing on-line requiere agilidad - cortesía de Pixabay

Pensémoslo, ¿quienes tienen relación directa con el mercado? ¿Quienes son los afectados directos de la turbulencia del cambio en este mundo actual?

Marketing es una disciplina extremadamente cercana al cliente/usuario, por tanto debe de estar centrada en este y estructurar su trabajo alrededor del mismo, y a ese enfoque responde la Agilidad. Organizaciones que quieran mejorar la velocidad, la previsibilidad, la responsabilidad y la capacidad de adaptación han de integrar Agilidad a sus procesos.

Las grandes campañas de marketing ya no funcionan, el marketing ágil consiste en lanzar pequeñas campañas de forma iterativa para inspeccionar y adaptarse a lo que ocurre afuera en el mercado.

Workfront define el marketing ágil como "un enfoque de marketing táctico en el que los equipos identifican y enfocan sus esfuerzos colectivos en proyectos de alto valor, llevan a cabo esos proyectos de forma cooperativa, miden su impacto, para finalmente mejorar sus resultados de forma iterativa y continua".

Aplicar Scrum a marketing permite manejar problemas complejos de forma creativa, productiva y consistente. Hay componentes de Scrum que funcionan bien, como son los eventos y artefactos, y hay que hacer ajustes menores en los roles y en la concepción de equipo.

La pila de producto en marketing puede tener muchos más tipos de cosas diferentes, elementos como la producción de anuncios, correos electrónicos, mensajes de twitter, libros electrónicos, todos ellos de naturaleza singular cada cual con su definición de hecho (DoD), y por ello el rol del Propietario del Producto puede estar representado por más de una persona. Por otro lado los múltiples canales y medios de comunicación de marketing ponen énfasis en la necesidad de una mayor separación en la especialización de los miembros del equipo, en los equipos de TI Scrum propicia una mayor igualdad a nivel de especializaciones y un bus factor más elevado que en equipos de marketing.

Quiero invitar a los interesados en aplicar Scrum a marketing sigan la "Guide to Using Scrum Methodology for Agile Marketing" de Andrea Fryrear.

Proceso de Publicación y Marketing Ágil en ciclos con mejora continua de una a varias semanas

Quiero invitar a leer el artículo de Jeroen Molenaar "Marketing scrum vs IT Scrum - two marketing case studies who now 'act first and apologize later'" que nos cuenta como ha aplicado Scrum con éxito en los departamentos de marketing de dos grandes empresas: ANWB y el banco ING. Ambas compañías están utilizando Scrum para el desarrollo de nuevas campañas, sus expresiones comerciales al completo así como en el nivel de desarrollo de productos.

El marketing ágil tiene su propio Manfiesto Ágil, con sus propios valores y principios que he traducido a continuación.

Valores del Manifiesto Ágil de Marketing:

Estamos descubriendo mejores maneras de crear valor para nuestros clientes y para nuestras organizaciones a través de nuevos enfoques para marketing. A través de este trabajo, hemos llegado a valorar:

• Aprendizaje validado sobre opiniones y convenciones
• Colaboración centrada en el cliente sobre silos y jerarquía
• Campañas adaptativas e iterativas sobre campañas big bang
• El proceso de descubrimiento de clientes sobre la predicción estática
• Planificación flexible vs. rígida
• La respuesta al cambio sobre el seguimiento de un plan
• Muchos pequeños experimentos sobre unas pocas grandes apuestas

Principios del Manifiesto Ágil de Marketing:

• Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de marketing que resuelve problemas
• Damos la bienvenida y planificamos para el cambio. Creemos que nuestra capacidad para responder rápidamente a los cambios es una fuente de ventaja competitiva
• Ofrecer programas de marketing con frecuencia, desde un par de semanas a un par de meses, con una preferencia a los periodos más cortos
• Gran marketing requiere una estrecha alineación con los equipos de negocio, ventas y desarrollo
• Construir programas de marketing en torno a individuos motivados, dándoles la entorno y el respaldo que necesitan y procurándoles confianza para que realicen la tarea
• Aprendizaje, a través del bucle de feedback construye-mide-aprende, es la principal medida del progreso
• Marketing sostenible requiere que se mantenga un ritmo y flujo constantes
• No tenga miedo al fracaso; simplemente no falle de la misma manera dos veces
• La atención continua a los fundamentos de marketing y un buen diseño enaltecen la Agilidad
• La simplicidad es esencial

¿Cómo pueden los equipos ganar conocimiento y despejar incertidumbre?

Equipo preparando spikes para adquirir conocimiento

Estuve conversando con un gestor de proyecto y me contaba que la madurez de los equipos que proporcionaban sus proveedores habituales había cambiado drásticamente. Históricamente, hace más de 5 años, en todo equipo había uno o dos seniors que lideraban las decisiones técnicas, lo que redundaba en un buen software. Hace 5 años los seniors empezaron a desaparecer paulatinamente de los equipos, pero si las cosas iban mal, como cliente presionaba al proveedor y aparecía un senior que salvaba el proyecto. Desde hace 3 años ya no hay seniors que salven proyectos... eso les llevó a comprender que la continuidad de los equipos, aunque sean externos, es crucial, que el conocimiento es un gran valor, así que hoy en día están construyendo software con equipos de Scrum pensados a largo plazo.

Recientemente estuve hablando con una programadora de un equipo que se había constituido a base de juniors, para ellos todo era nuevo, miraran a donde miraran todo era desconocido, la experiencia de sus compañeros recién salidos de universidad era mínima, y me preguntaba qué podía hacer. Le contesté que había que adquirir conocimiento y despejar incertidumbre, era hora de crear spikes exploratorios y traer visibilidad al trabajo para construir funcionalidades de forma eficiente.

Un spike viene a ser una actividad de desarrollo en forma de historia técnica que se incluye en la pila de producto con el objetivo de dar respuesta a una cuestión o de reunir información para una toma de decisión posterior o el diseño de una solución.

Los spikes también sirven para adquirir el conocimiento previo necesario para entender mejor la solución y/o la necesidad asociada a una historia de usuario y así reducir la incertidumbre respecto a la implementación de la misma. Esta técnica se conoce como "construir un spike" y se pueden materializar en pruebas de concepto o prototipos que permiten evaluar la viabilidad de una historia usuario. En este caso los resultados de la actividad exploratoria nos permiten tomar decisiones adecuadas para refinar o definir el alcance de una historia de una forma sólida.

Existen dos tipos de spikes:

• Spike técnico: si no estamos seguros de cómo desarrollar algo desde un punto de vista técnico creamos este tipo de spike, una breve actividad que se centra en encontrar un enfoque de desarrollo, en determinar la factibilidad y el impacto de las estrategias de diseño.
• Spike funcional: sirven a los equipos para descubrir los detalles de las funcionalidades y los diseños a través de la creación de prototipos y llegar a entender exactamente lo necesita el cliente.

A parte de ganar conocimiento y despejar dudas, los spikes permiten a los equipos dar estimaciones sólidas a historias de usuario posteriores. Al tratarse de exploraciones rápidas, los spikes deben de estar limitados en el tiempo (time boxed), usualmente de unas horas o unos días.

Los spikes se escriben en forma de historia técnica, imaginemos la siguiente historia de usuario de ejemplo:

Como ciclista

Quiero pagar mi compra con tarjeta de crédito

Para poder comprar accesorios para mi bicicleta

Historia para la que podemos construir un spike en forma de la siguiente historia técnica:

Explorar la pasarela de pago de tarjetas de crédito de nuestro banco

para conocer la viabilidad de la inclusión de la misma en nuestro producto

Donde los criterios de aceptación hacen referencia a las cuestiones que necesitan ser respondidas.

Como los demás elementos de la pila de producto los spikes se demuestran en la revisión de sprint donde el Propietario del Producto las ha de aceptar.

Son elementos de la pila adaptados:

• Pequeñas
• Demostrables
• Dan respuestas basadas en evidencia:
• Pruebas de concepto o prototipos funcionando
• Elementos existentes similares
• Limitadas en el tiempo
• El fracaso es uno de sus resultados, su objetivo es que aprendamos o tengamos criterio para la toma de decisiones

Quiero agradecerle a Cristina la conversación que tuvimos y que dio pie a este post :-)

¿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 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 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"