¿Qué es la velocidad ágil o en Scrum? Aclaración de dudas frecuentes

La velocidad se calcula sumando el número de puntos historia (según la unidad y escala que uses) que se estimaron para cada historia de usuario (o para cada bloque de valor añadido al producto, es más correcto verlo así porque historia de usuario es funcionalidad y hay otras cosas no funcionales que también añaden valor al producto, lo veremos luego) que se ha terminado durante una iteración o sprint.
Es decir, por ejemplo, si el equipo terminó tres historias de usuario en el Sprint, y cada una de ellas se había estimado en cinco puntos historia, entonces su velocidad en ese Sprint fue quince puntos historia.
Hasta aquí el concepto se entiende bien al explicarlo, lógico, parece bastante razonable, pero a la hora de la verdad… empiezan las dudas. En todo proyecto de implantación de agilidad o Scrum en que participo raro es que no empiecen a surgir preguntas como estas…

  • ¿Y los bugs? ¿Las mejoras? ¿Qué pasa si hay que solucionar una incidencia durante el Sprint? ¿Todo eso no suma velocidad?
  • ¿La velocidad es las suma de las horas estimadas de cada historia de usuario completada en el sprint o deberían sumarse las horas reales dedicadas (que probablemente no coinciden con las estimadas)?
  • Las historias casi casi casi terminadas, medio terminadas o lo que quiera que llevemos de ellas… ¿suman velocidad?

 
Vamos ello…

Entonces, limpiar bugs, refactorizar, mirar el SGBD, pruebas… ¿cuentan en la velocidad?

¿Quién decide que algo es valioso (en términos de negocio) para el producto? Efectivamente, el product owner, ¿y dónde está lo que añade valor (de negocio) al producto? Eso es, en el product backlog.
Entonces, por ejemplo, una refactorización, una migración de gestor de BBDD, etc., que no son añadidos de funcionalidad, una vez completados… ¿suman velocidad? Depende del product owner. Ejemplos:
a) Si la refactorización (migración de BBDD, limpieza de bugs, etc.) es muy importante, grande, necesaria, consumirá gran parte del Sprint, es de esas que si no la hacemos el software se viene abajo, etc., dicha necesidad debería estar en el product backlog (un product backlog no solo tiene historias de usuario, realmente tiene ítems de valor para el producto), se entiende así que es importante en términos de negocio. Así será explícita de cara al product owner, visible, etc. El negocio ha apostado por la necesidad de refactorizar. Y por ello, viniendo del product backlog, una vez terminada sumará velocidad.
b) Si la refactorización (pruebas, bugs, etc.) es rutinaria, típicamente, es una tarea asociada a la realización de las historias de usuario, entonces debería estar en el sprint backlog y no sumaría velocidad, se entiende que es una tarea necesaria para la implementación de las historias de usuario (como puede ser desarrollarlas, diseñarlas, probarlas, etc.) que hay en el product backlog y que terminadas estas, ellas, las historias de usuario, serán las que sumen velocidad (implícita queda la tarea de refactorizar o similar que fue necesario para terminar la historia de usuario).

¿Medimos la velocidad con el esfuerzo estimado o el real?

La velocidad mide “trabajo realizado” en función de la “estimación inicial”.
Es decir, si mides la velocidad en horas, y dijiste que la historia de usuario A os llevaría 20 puntos (o lo que sea en la escala que uses), y la terminasteis, pero realmente os llevó a ojo unos 40… la velocidad que aporta esa historia de usuario es de 20.
Sé que esto a muchos equipos les choca la primera vez… “pero si aunque estimásemos 20 puntos historia realmente hicimos 40”. Cierto, pero con todo esto queremos ver la diferencia entre cuánto pensábamos, lo que estimamos, y cuánto realmente fue, afinando así el método de estimación.
En este punto, facilita estimar en puntos historia frente a horas, ya que te abstrae más, ya que el punto historia es un valor relativo.

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.
 
 

Últimas entradas de jgarzas (ver todo)

6 comentarios en “¿Qué es la velocidad ágil o en Scrum? Aclaración de dudas frecuentes”

  1. 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!

  2. 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.

    1. 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.

  3. 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.

    1. 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.

    2. 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.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba