Porqué los Story Points deben morir y te ayudamos para conseguirlo

Login

Register

Login

Register

Blog

Porqué los Story Points deben morir

Hace tiempo que no damos Story Points en las capacitaciones que Agile611 proporciona. Los story points deben morir y dejarnos en paz.

Lo hacemos porqué nos parece perpetrar la inmadurez en los equipos que acompañamos.

Os voy a justificar porqué hacemos esto en las siguientes lineas.

¿Por qué los story points deben morir?

Todo se reduce a comprender la naturaleza de la complejidad y no a intentar utilizar enfoques lineales para desafíos no lineales. 

Estamos trabajo en entornos complejos, donde tenemos que fomentar prácticas emergentes para solucionar esos problemas que tenemos todos los días.

Agile es bueno en lo que es bueno: manejar problemas complejos (como proyectos de software y otros entornos similares).

Agile comienza a apestar cuando más introduces mecánicas que vienen del cuadrante complicado donde impera el reino de la resolución de problemas.

Es decir, mecanicista, determinista y reduccionista. Esos conceptos se remontan una manera de trabajar en cascada, el taylorismo y la era de la producción en masa.

Para ayudar a comprender Cynefin aquí en referencia a los dominios de los tipos de problemas.

Profundizo en el video que os adjunto que otras opciones hay para superar a los story points y la velocity.

Más bien te justifico el porqué que hay detrás de porqué no deberías usar puntos de la historia.  

Además del inventor original de la idea inicial, Ron Jeffries, te está diciendo que no los uses de manera abierta.

¡Adiós, velocity! Métricas Kanban como alternativa a los puntos de historia y la velocity del equipo

La adicción de un pronóstico a la manera de trabajar en cascada exigía algún mecanismo de pronóstico ágil.

La ruta reduccionista popular de trabajar en cascada es romper todo en sus piezas constituyentes.

Una vez que tenemos todas las partes descompuestas, las dimensionamos, las sumamos y miramos la totalidad.

Aquí se aterriza el sueño de cualquier director de proyecto.

Luego viene el determinismo. La suma del trabajo dividida por la velocidad del equipo determinará cuándo se realiza el trabajo. Totalmente lineal y falso.

Todo es un pensamiento muy lineal y podría funcionar si el trabajo no fuera complejo.

Pero, por desgracia, los problemas de hoy suelen ser un problema complejo con muchas más incógnitas que partes conocidas.

En un dominio complejo, no intentemos utilizar el reduccionismo y el determinismo, por ejemplo los puntos de la historia y la velocity.

Cuatro alternativas para evolucionar de los story points

Mencionaré algunas otras opciones para señalar historias, pero no describiré en profundidad cuáles son aquí. Eso están las capacitaciones.

A continuación, se describen brevemente cuatro alternativas de estimación de Wisdom of Crowds, simulación de Monte Carlo y probabilidad bayesiana.

Hay un gran video donde Dave Snowden (el padre del modelo Cynefin) dice (algo así como): cuando estás en el dominio complejo, la estimación de Wisdom of Crowds es la forma correcta de estimar.

Estoy bastante seguro de que estaba en este video sobre cómo aplicar Cynefin a Kanban.

Creo que Snowden está en algo aquí, y Wisdom of Crowds (también conocido como Blink Estimation) sería mi primera sugerencia para comenzar a realizar algunos experimentos.

Hice algunos experimentos en esta área poniendo la estimación relativa a prueba. Me encantaría ver más experimentación en esta área y aprovecharía la oportunidad para hacerlo. Si tienes alguna experiencia, por favor compartéla.

Rendimiento o recuento de historias

Otra opción es el rendimiento (también conocido como recuento de historias).

Esto se aleja un poco del determinismo, pero aún se basa en el reduccionismo.

Idea similar a la velocity, pero la diferencia clave es que ya no necesitamos estimar el tamaño de cada elemento de trabajo.

Una vez que se ha determinado que un elemento es lo suficientemente pequeño como para ser viable, ingresa al sistema de flujo y los elementos se cuentan durante un período de tiempo para obtener un rendimiento.

Sin duda, es una mejora, ya que se elimina el tedio de la talla. Este método ganó especial popularidad gracias al movimiento #NoEstimates.

Simulación de Montecarlo

La simulación de Monte Carlo es otro mecanismo. 

Por lo que (creo que) entendí, todavía necesitas algo de reduccionismo.

La simulación de Montecarlo muestra las probabilidades de que los elementos realizados se completen a lo largo del tiempo basándose en datos anteriores.

Joseph Pelrine siente que Monte Carlo puede tener fallas en la estimación ágil.

Es más inteligente que yo y aquí hay algunos trabajos que ha realizado sobre la mejora de la calidad de las estimaciones con psicología y psicometría.

Todavía estoy indeciso porque no he hecho una investigación profunda, experimentación o investigación al respecto en muchos equipos, pero creo que esto va en la buena linea.

Probabilidad bayesiana

La última de la que también sé muy poco, pero me interesa mucho saber más, es la probabilidad bayesiana.

Uno de mis intereses secundarios son los submarinos y las naves militares en general.

En el libro Blind Man’s Bluff: The Untold Story of American Submarine Espionage de Sherry Sontag, Christopher Drew, Annette Lawrence Drew, comparten al menos dos historias sobre el uso de la probabilidad bayesiana para localizar submarinos hundidos.

¡Me explotó la cabeza! Necesito saber más sobre este método y si y cómo podría usarse para pronosticar en el dominio complejo. Seguiremos trabajando y investigando esta parte porqué me interesa mucho seguir.

El señalamiento de historias de usuario está anticuado y el creador de los Story Points hoy lamenta haber presentado el concepto.

Para resumir, los Story Points y la velocity son enfoques lineales basados en el reduccionismo y el determinismo.

Como tales, no se ajustan bien a los problemas en el dominio complejo no lineal, como el software o los problemas del mundo de hoy día.

WhatsApp chat