Hace unas semanas hablábamos de si estimar, como tal, era un desperdicio. Yo te expuse que sí, que lo es, aunque muchas veces es un desperdicio que no se puede evitar, pero que, como tal, como desperdicio, se debía controlar y se debía reducir e incluso… ¿eliminar?
Te contaba en aquel post que estimar era ese tipo de cosas que, muchas veces, no se pueden evitar (lo que no quiere decir que no sea evitable en ciertos casos), porque ayuda otros a hacer previsiones (de cuánto se añade al producto por Sprint, que no hay que confundir con saber qué tendremos en cierta fecha, recuerda, que no te confundan, en agilidad hay fechas pero el alcance es variable).
O es útil porque a nosotros, cómo equipo, nos ayuda a mejorar, a medir la velocidad y a intentar incrementarla (ya sabes, velocidad como ritmo sostenible y no hacer las cosas demasiado rápido metiendo deuda técnica… que luego vuelve).
En esta línea, como te dije antes, deberíamos buscar estimar de la manera que tenga menos desperdicio (o #noestimates, lo dejo para un poco más adelante).
Hay cosas obvias, como el Time-Box y reducir el tiempo de los planning (si usas Scrum), tener un método de decisión en equipos auto-organizados que sea rápido, etc., pero entre todos los anteriores hay uno que algunos equipos ni se cuestionan, que es dogma (aunque, como te reconoceré más adelante, puede que sea inevitable), que es… la estimación con Punto Historia.
Los Puntos Historia, de los que yo he hecho mucho uso en equipos, y de los que he escrito mucho, nacen de la necesidad de ponderar historias de diferente tamaño. Y ahí, en la necesidad que llevó a su creación está la disfunción… tener historias de muy diferentes tamaños es un desperdicio que lleva, entre otros, a tener que usar el Punto Historia.
Sé que en algunos sitos copados de deuda técnica, legacy y walking deads plantear que, a corto plazo, las Historias sean del mismo, o similar, tamaño es utópico (lo que no quita que sea un objetivo de mejora a perseguir). Y por eso existe el Punto Historia.
Pero piensa que si todas las Historias fuesen más o menos del mismo tamaño, y pequeñas (ojo), la velocidad se mediría en número de historias de usuario en “done” al final de Sprint y no necesitaríamos tanto del Punto Historia.
De hecho, eso reduciría drásticamente el tiempo en estimar, sólo habría que basarse en los datos de Historias terminadas en anteriores Sprint, rápido, y no en tener que hacer consensos y planning pokers para ir ponderando cada una de las Historias según un rango de Puntos Historia. Y esto huele mucho a #noestimates.
Pero no sólo eso, el tener Puntos Historia lleva a otras cosas (más desperdicio). Como tener que contar el número de Historias al final del Sprint (no es lo mismo terminar con 40 Puntos Historia y 2 Historias, que con 40 Puntos Historia y 40 historias). Saber si estamos acertando en las Estimaciones (cuándo ponemos un 8… ¿es realmente un 8?). Tener que recordarnos que en las famosas barajas de plannning póker habría que tirar a la basura, por lo menos, de la carta con el 5 para arriba.
Aunque, realmente, recuerda, el problema no es del pobre Punto Historia es de… tener Historias de muchos, y grandes, tamaños. Que no sólo llevan al Punto Historia, y sus derivados, sino también acercan al cascada (esto para otro post, si no lo he escrito ya).
Controlando el Time-Box de los planning, con consensos rápidos, experiencia e historias que no son muy grandes, aun usando el Punto Historia tampoco estamos ante grandes desperdicios, comparado con otras cosas que hay por ahí. Pero si que conviene hacer esta reflexión para no dejar libre al Lado Oscuro, controlarlo, reducirlo o, en definitiva, saltar de nivel y mejorar.
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
Buenos días:
Tengo dudas de cómo calcular el Time to Market para un equipo que trabaja en agile. Podeís indicarme si tenéis una publicación que me ayude?
Muchas gracias
Hola Javier,
Me cuesta ver y entender tu planteamiento. Si hiciéramos que las historias de usario se adaptaran al tiempo de una tarea, entiendo que ahorraríamos tiempo a la hora de estimar. Pero discrepo un poco:
– El poder hacer una estimación con el equipo, ayuda a ver distintos puntos de vista y ver cosas que puede que no hubieras contemplado.
– Totalmente de acuerdo contigo que historias de más de 5 puntos deberían de poder desglosarse en otras más pequeñas, sino la estimación se convierte en adivinación
– Si hiciéramos que una historia fuera tan pequeña como una tarea, estaríamos más pendientes de su tamaño que de la propia historia definida por el PO
Todo esto no quita el que al equipo le cueste separar los conceptos de complejidad y tiempo de desarrollo. Cada equipo al final encontrará una equivalencia entre historia y horas ideales, pero eso lo dará al final la velocidad en base a como estime el equipo.
Aún y así, siendo sincero, tengo que encontrar y hacer ver al equipo como estimar para que sprint a sprint, el tiempo dedicado a la estimación sea cada vez menor y se convierta en hábito casi instantáneo, eliminando así el desperdicio que indicas.
Seguiré profundizando en este tema para encontrar esa solución que aún se antoja lejana.
Gracias por todo lo que das a la comunidad Agile!!!!
Pues yo estoy totalmente de acuerdo, aunque añadiría algunos matices:
– es algo que hay que tender a reducir, pero yo creo que el desperdicio solo se encuentra en una mínima parte del tiempo dedicado al consenso en la que se acuerda el número final, el resto del tiempo es el mismo en ambos escenarios, es decir, debo de dedicar tiempo a refinar para sacar el tamaño el cual será el mismo tiempo (prácticamente) para realizar la división en historias más pequeñas.
– el tiempo en contar puntos y proyectar fechas creo que es inapreciable ya que hay infinidad de herramientas que lo automatizan y facilitan dichas proyecciones ayudando al PO y cualquier otro stakeholder facilitando la transparencia (siempre que se usen correctamente)
– por otro lado hay que tener mucho tacto con los equipos en cuanto al uso de los puntos, deben entender muy profundamente su uso y no caer en la tentación de mal usarlos.
– por último y de cara a minimizar el desperdicio en mi opinión, en el caso de scrum, es el PO el que debe como responsable del backlog, mantenerlo en cuanto al tamaño de las historias ya que en este caso el tiempo dedicado es de una sola persona vs todo el devteam, facilitando el consenso posterior por el equipo.
Un saludo y gracias igualmente por mantenernos siempre alerta!
Muy interesante el artículo, aunque igualmente siento que se está perdiendo el «punto de la historia» (pun intended), que es que las historias de usuario tienen normalmente tres partes:
– el actor de la historia
– aquello que el ScrumTeam va a implementar para satisfacer una necesidad específica
– la necesidad subyacente específica (la que el cliente no te dice, sino la que tienes que averiguar)
El tamaño de la historia debe ser puntual, su esfuerzo debe ser enfocado. El tamaño de la historia debe reflejar la implementación más simple para satisfacer el requisito de negocio, ni más grande ni más chica. Y nunca debemos forzar los tamaños de las historias de usuario, porque de hecho es inviable que, bajo ese precepto, todas sean de tamaños similares.
Sí, te puede tocar una seguidilla de historias que son diferentes en cuanto a requisitos y/o implementación, pero así y todo luzcan similares en esfuerzo. Eso no quiere decir que todas lo sean, y de hecho Agile te dice que tienes que presuponer que no. Forzar a que las historias de usuario sean similares en esfuerzo por el mero hecho de erradicar los puntos de historia y estimar directamente en historias proporcionales sería un despropósito de Agile. Sí, tus plannings serían más directas y (quizá) se podría reducir el tiempo invertido en ellas, pero el costo de hacer una cosa así es tergiversar el requisito o la implementación para que así sea. Hasta incluso podrías estar cayendo en el anti-patrón de micromanagement (donde las historias representan tareas en lugar de historias) si no tienes el suficiente cuidado.
Desde este punto de vista humilde, lo veo utópico y poco práctico si se quiere mantener el espíritu de las metodologías Agile y la de historias de usuario. O sea, para llegar a una cosa así, hay que romper las bases de una herramienta en lugar de jugar libremente basado en sus reglas y principios.