Pages Menu
Categories Menu

Posted by on Mar 25, 2014 in General | 0 comments

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

 

 

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.
Javier Garzás

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This