Story Points vs Hours

Llevo meses mascando este post, la verdad es que he tenido varios debates con otros ingenieros, y no hay una opinión convencida por ninguna de las dos alternativas. Lo mismo se puede deducir de una búsqueda rápida en google por: Story Points vs hours ... veréis que no son pocos los post relativos a esta temática.

Creo que lo más razonable es exponer pro's y contra's de ambas posibilidades y a posteriori explicaré que decisión hemos tomado en Tritium y las motivaciones.

En cualquier caso, no voy a poder ser muy objetivo, por que no he vivido ninguna implementación por el momento basada en Story Points, en los equipos en los que he trabajado trabajamos con esfuerzo.

Story Points

Como bien podéis deducir del nombre se trata de otorgar una valoración a la tarea, en general suelen ser aplicados a historias (Story) Y ese es para mi el enfoque ideal de aplicación.

Uno de los factores más importantes a considerar es que los Story Points valoran la complejidad, ni el esfuerzo ni la duración. Y para mi ese es uno de los puntos más importantes para, en función de tus necesidades, descartar esta opción.

No existe una definición clara en relación al proceso de estimación en ninguna de las metodologías ágiles, suele ser habitual para facilitar la asignación de complejidades utilizar la serie de fibonnaci 1 3 5 8 13 21 34 ... por ejemplo.

En general se consideran, y me sumo a la consideración, una perfecta herramienta de valoración/estimación a largo plazo. Pero poco recomendable para gestionar el SPRINT PLAN.

Existen pero equipos que se sienten cómodos haciendo uso de estos, y obteniendo métricas de velocidad de sus equipos en base al número de puntos que son capaces de resolver en cada SPRINT.

Esta métrica, primordial para los equipos ágiles, tiene un pero, y es que no pueden ser extrapoladas a otros equipos, la velocidad en puntos, es algo subjetivo, en función del valor que le des a una historia. Un equipo puede otorgar una complejidad 3 a una historia que para otro sea complejidad 8... 

Este factor es, desde mi entender, contraproducente cuando la organización dispone de más de un equipo, no obtienes métricas que te ayuden a identificar puntos de mejora en la organización. La velocidad es algo atómico para cada equipo. En cambio puede ser suficiente para una organización monoteam.

Otro factor contraproducente es como resolver la pregunta, al más puro estilo "The Simpsons" de "¿Cuánto falta?" Recuerdo que los Story Points es una métrica de complejidad, no de duración ni esfuerzo ... por lo que de nuevo nos encontramos con falta de herramientas a la hora de resolver esta habitual pregunta. 

Siempre podemos optar por, viendo el número de puntos restantes para cumplir con el objetivo y la velocidad del equipo, deducir el número de SPRINTS que nos faltan para cumplir como el hito requerido. Pero dificulta la transparencia de la información. 

Hours

La estimación por tiempo tiene otras complejidades, pero tiene la ventaja de la transparencia, la comunicación es en una unidad temporal que otros miembros externos al equipo de producción entienden, el tiempo.

Eso sí, hay que dejar muy claro en cualquier caso, que las estimaciones son sobre esfuerzo, jamás sobre duración, la duración es otra herramienta de estimación que se convierte en peligrosa ...

Voy a tardar 8 horas, por tanto lo tendrás mañana. !!!ERROR!!!!

Como diría mi profesor de lógica, A si B, no A --> no B ... ya sabemos que es imposible trabajar sin interrupciones, para que nos vamos a engañar. Las tareas deben estimarse en esfuerzo, cuanto tiempo estimado requiere esta tarea para ser desarrollada. 

La duración la establece el SPRINT, hay que evitar en la medida de los posible realizar entregas parciales dentro de una unidad de planificación. Las entregas se realizan al final del SPRINT. Por lo que la duración no es representativo en esta situación.

En cualquier caso existen muchos contras de fundamentar las estimaciones en horas. Es algo que sucede de manera habitual en entorno "Consultoría", las estimaciones no se realizan en base a complejidad, si no en base "al tiempo disponible". Es decir se suele planificar en base a un budget definido de tiempo provocando las indeseadas situaciones que muchos de nosotros conocemos.

En ese sentido, medir la complejidad del proyecto a nivel global, y conociendo nuestra velocidad en puntos, nos puede dar un horizonte muchísimo más fiable que nuestras estimaciones basadas en duración o esfuerzo (Vamos a tardar 1800 horas, o lo vamos a tener en 2 meses... qué escalofríos!!!)

Solución Mixta 

Creo que en este post podéis encontrar una explicación perfecta de mi opinión. Me parece una solución equilibrada y es utilizar ambas métricas para diferentes necesidades.

Estimar las historias del PRODUCT BACKLOG con Story Points, que nos ayuden a estimar la complejidad de la historia, pero una vez aplicamos el breakdown en tareas y trabajamos en el SPRINT PLAN utilizar horas en base a esfuerzo.

Cito textualmente: 

No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning.

Poco más me queda añadir

El año ágil en Tritium

La adopción de las metodologías ágiles en Tritium sigue un paso lento pero firme, durante el presente año, integrando la herramienta Assembla, hemos dado un primer salto de calidad.

Además de herramientas imprescindibles como son el repositorio de código, la wiki (que aún infra-utilizamos) la herramienta de management ha empezado a dar sus frutos.

Iniciamos el proceso de adopción con SPRINTS de 14 días, que redujimos a 7 por que estamos en un momento de iteración de producto que nos exige más flexibilidad en la adopción de cambios de prioridad y liberación de nuevas features.

Ese cambio, pese a que inicialmente supuso un aumento de tensión, fue algo positivo que ahora está completamente adoptado por el equipo.

Es habitual que planifiquemos siguiendo con las recomendaciones de SCRUMBAN, dejando lacks de tiempo para incidencias/imprevistos y investigación (si es necesario) por lo que nuestro límite de planificación suele rondar las 120h

En estos meses, dado nuestro volumen de equipo, y el trabajo tan continuo, no ha sido necesaria la adopción de los StandUp meeting, pero sucederá tarde o temprano.

Otra de las conclusiones a las que hemos llegado es que disponer de un SPRINT Cardwall digital es perfecto, compartes la situación a tiempo real del SPRINT, es distribuido (puedes consultarlo en casa o en cualquier lugar) y además actualiza en tiempo real en función del reporting de dedicación de cada persona.

En cambio, no resulta tan práctico y tenemos sin duda que mejorar, la toma de decisiones en la definición de nuevos sprint PLAN. Tenemos que trabajar más en mejorar el PRODUCT BACKLOG para tener toda la información en los SPRINT meetings.

Y para este próximo año vamos a crear un STORY BOARD que represente el product backlog de Force Manager, y que nos ayude en la priorización y la toma de decisiones.

Otro de los objetivos que nos marcamos para este inicio de 2012 es el despliegue de un entorno de integración y la configuración de un entorno de integración continua. 

Step by step ...

Referencias:

• http://blog.mountaingoatsoftware.com/tag/story-points
• http://scrummethodology.com/scrum-effort-estimation-and-story-points/
• http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-better-than.html
• http://www.infoq.com/news/2009/09/story-points-versus-hours
• http://www.tommycode.se/2011/10/story-points-vs-hours.html
• http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html

Un fuerte abrazo,