Actualización: Este post es antiguo, después acabamos descubriendo mejores maneras de trabajar, como que funciona mejor no usar Puntos Historia, que conllevan desperdicio (te dejo post actualizado que explica esto), o que si los usas que sea sólo para estimar, la velocidad mejor contarla en número de Historias que se han convertido en Working Software o Solutions (si no trabajas en software), te dejo un vídeo más reciente que actualiza esta información.
La velocidad se calcula sumando el número Historias que se ha terminado durante una iteración o sprint.
Las historias casi casi casi terminadas… ¿suman velocidad?
No. Porque raro es que una historia de usuario al 90% supere el acuerdo por el cual el Product Owner da por terminada una historia de usuario, lo que se llama “acuerdo sobre el –done-“, el Definition of Done. Recuerda, o léete, aquello de en un proyecto ágil, acordar una buena definición de lo que significa terminado (el done).
Historia de usuario al 90% no superará el “done”, entonces no está terminada, entonces no suma velocidad.
Y así reforzamos ideas ágiles (y de Kanban), como aquello de que trabajo medio hecho… genera desperdicio.
—
Junto con este post, te recomiendo que leas también como estimamos proyectos Scrum o en general ágiles.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Hola!! Historias de usuario no terminadas que le faltaron poco o casi nada, se vuelven a estimar para el próximo sprint? O se mantiene lo estimado?
Gracias!
Hola Javier
Una duda en relación a que no suman las HU no completadas.
Dado que no cumplen con la DoD, está claro que no generan valor al producto y por tanto no deben darse por completadas pero, no estoy del todo de acuerdo en que no deban tenerse en cuenta a la hora de computar en la velocidad del equipo. Si queremos conocer la velocidad del equipo, las subtareas de la HU completadas que estén estimadas es trabajo realizado al fin y al cabo y así lo reflejo en el Burndown Chart del sprint.
Hay HU lo suficientemente complejas como para necesitar de gran parte del sprint para completarse (2-3 semanas). No me parece justo para el equipo (y tampoco motivante) que no se refleje en el Burndown Chart las subtareas de las HU que se van completando y que se vean los avances producidos. En muchos de estos casos, podemos llegar a los últimos días del sprint sin la HU completada y puede dar una falsa apariencia de bloqueo o estancamiento para el PO o a los stakeholders (comerciales, etc.) que quieran consultar el estado del sprint.
¿Qué opinas?
Muchas gracias de antemano.
Un saludo,
Jorge.
Yo también pensaba algo parecido, de hecho muy a menudo los burndown charts no me eran muy útiles por lo que comentas, llegaban al final del sprint y como la HU no estaba en Done no computaba. Los últimos días se generaba un escalón al ir cerrando todas las historias.
Después de darle muchas vueltas llegué a la conclusión de que:
* Si una historia de usuario lleva un sprint entero completarla seguramente era reducible a 2 o 3 más simples y nucleares.
*Siempre intento priorizar el cierre de HU des del principio del sprint, si no lo consigo lo que consta en el burndown no es representativo. ( por el efecto escalón que he comentado antes). Y si tenemos algún contratiempo hacia el final del sprint no nos quedamos sin valor para entregar, porque ya hay HU en Done.
* A menudo a mi equipo le motiva ver un resultado de su trabajo, si las HU son completables en pocos días les motiva para seguir con el sprint, si después de 10 días aún no han visto un «resultado» (pondría muchas comillas aquí) se desmotivan y dispersan.
Hola,
No se si la respuesta a las preguntas planteadas anteriorimente en este post fueron respondidas por otro medio, pero me gustaría saber que opina Javer sobre las mismas.
En particular la pregunta de Cecilia toca un tema que nos está sucediendo actualmente (recién estamos adoptando metodologías ágiles en la empresa).
Para un sprint se estimó una historia en 3 puntos y no la pudimos terminar, por lo cual no contó para la velocidad del sprint.
En el equipo decidimos junto con el PO el pasarla al siguiente sprint y se nos planteó la duda de que hacer con la estimación:
* ¿Debíamos mantener la misma estimación de la historia a pesar de que el 80% estaba terminada?
* ¿Debíamos re estimar lo que quedaba? Si hacemos eso ¿que pasa con los puntos invertidos en el sprint que acababa de finalizar? (esto tiene relación con lo planteado por Jorge)
Finalmente lo que hicimos fue pasar la historia al sprint siguiente pero manteniendo la estimación original, pero sinceramente no quedamos muy conformes con eso.
¿A alguien le ha pasado algo similar? ¿como lo resolvieron?
Desde ya muchas gracias
Saludos.
Hmmm lo único que se me ocurre es que dividan esa HU en otras HU más pequeñas y que lo ya hecho lo asuman en el sprint anterior y lo que haya faltado completar para el sprint siguiente. De todas formas me gustaría leer lo que opina Javier.
Hola,
Nosotros lo que hacemos en esa situación que describes es reestimar la historia con lo que queda por hacer.
Cada sprint que se acaba, «desaparece», por lo que poco importa lo que haya sucedido en el anterior, más allá de aprender de el y aplicarlo en el siguiente. Por ello, consideramos que esa historia no tiene sentido que aparezca en el nuevo sprint con una estimación que se hizo hace 2, 3 o 4 semanas, si no que hay que valorarla de nuevo, con la experiencia que tenemos ahora, para intentar que el Sprint que vamos a arrancar salga mejor que el anterior y así ir progresando.
En cualquier caso, la mejor manera de minimizar que suceda esto es hacer HU más pequeñas (sin llegar al otro extremo y llegar a la «muerte por gestión»). Sorprende la de veces que al arrancar un sprint no vemos como dividir funcionalmente (esto es importante) una HU y luego en la retro, una vez tuvimos que plantarle cara a esa HU, se nos ocurren mil maneras de hacerlo. Ahí es donde nosotros conseguimos aprender realmente.