Como sabes, si pasas por este blog, el tema de la estimación (más ágil, menos ágil, noestimación, etc.) es algo que suelo tocar con frecuencia, desde hace muchos años (que para eso ya va a cumplir 11 este blog).
De hecho, sólo en estas últimas semanas te he dejado 3 post sobre el tema (Rayleigh para Dummies 1, Rayleigh para Dummies 2 y Puntos Historia… ¿Horas o Complejidad?). Y hoy voy con otro más, que se deriva del último, del de la semana pasada, sobre este tema de la estimación, que sé que es un tema aparentemente simple… pero que la realidad es que es difícil de entender, e interiorizar (y fácilmente malinterpretable), sobre todo si eres nuevo en gestión ágil.
Sé que es un tema aparentemente simple, pero realmente difícil de entender (por eso en la jornada del 27 de abril, sobre agilidad avanzada, en Madrid, será uno de los puntos fuertes a tratar)
Voy a obviar en este post entrar en cuestiones básicas de estimación, de qué es la velocidad, etc., porque sino esto se puede extender demasiado. Si necesitas entrar en temas de más base léete la guía de supervivencia en estimación ágil, que para eso la escribimos hace ya su tiempo.
Opciones (típicas) en agilidad a la hora de estimar
Teniendo claro que no hay una única opción, que siempre pruebes, experimentes, que seas humilde, dudes, etc., en agilidad, típicamente, a la hora de estimar lo que seremos capaces de hacer en un próximo Sprint (no entro aquí en cuestiones de más alcance, como los roadmaps) suele haber las siguientes opciones:
1 – Punto Historia (uso de una una serie, típicamente basada en la secuencia de Fibonacci), interpretado cada número, principalmente, como grados de complejidad.
2 – Punto Historia (uso de una serie, típicamente basada en la secuencia de Fibonacci), interpretado cada número, principalmente, como esfuerzo o tiempo ideal, en jornadas u horas, según aplique. Ojo, que aquí hay a la vez dos estrategias diferentes, una cosa es interpretar el PH como tiempo y otra como esfuerzo (que no es lo mismo).
3 – Tiempo ideal (rango continuo), directamente, por ejemplo, este item nos llevará 3 jornadas y media (ojo, una cosa es estimar en tiempo, opción valida, como te conté en Puntos Historia… ¿Horas o Complejidad? y otra medir en avance en tiempo transcurrido, ojo, que lo segundo no tiene sentido, horas en la oficina vs ideas y conocimiento aportado). Ojo, aquí hablo de tiempo, no esfuerzo, es similar a una de las variantes de la 2, pero sin usar escalas tipo Fibonacci.
4 – Número de Items que creemos que seremos capaces de hacer en el Sprint.
5 – No estimar, en base a una ordenación por valor (noestimación), que igualmente debería existir en los anteriores, ir tirando por orden.
De todos los anteriores puedes encontrar n artículos, tweets, etc., apoyando una de ellas frente a otra. Hasta interesantes discusiones entre «los que saben», los creadores de las diferentes interpretaciones (véase como ejemplo el extracto de Tweets de la siguiente imagen).
Todas las anteriores tienen sus pros y contras, todas dependen de las circunstancias y el nivel de madurez en que esté un equipo, su situación de partida, la situación del producto con el que trabaja, etc.
Hace años, como te conté en Puntos Historia… ¿Horas o Complejidad?, la estrategia 1 era muy popular, y sigue siéndolo, pero muchos líderes en el mundo ágil se movieron de la 1 a la 2 (nosotros, mismamente, en 233, pasamos de estimar usando la opción 1 a la 2), recordando que la 2 tiene dos variantes, tiempo o esfuerzo, que son diferentes y hay quien usa una y quien usa la otra.
La opción 3 en sitios poco maduros puede ser peligrosa (por lo de caer en el Lado Oscuro, problemas de estimación, compromiso, con el management, etc.), si no se entiende bien, etc., pero es muy típica en aquellos muy del mundo eXtreme Programming (más que en Scrum).
La opción 4 también es muy eXtreme Programming, y a mi me parece de lo más recomendable, pero requiere de poder tener items a estimar lo más pequeños posibles y todos de un tamaño similar, lo cual no todos los equipos pueden hacerlo.
La opción 5 tiene muchas interpretaciones, cada uno la entiende de una manera, y es típico, como siempre opcional, verla acompañada de prácticas que se suelen usar con Kanban (como los Gráficos de seguimiento en Kanban).
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
¡Holas! ¿Qué eventos conllevaron a que 233 cambiara de la 1 a la 2?
Hola! ¿Tendrás algún video/post donde explicas el punto 2 de la estimación y ambas variantes? No estoy logrando bajar a tierra y práctica ese item. Gracias
Mira a ver este… https://www.youtube.com/watch?v=GBC4gh7iUaM