Estimaciones con SCRUM

Una de las cosas que más quebraderos de cabeza suele darnos cuando hemos decidido adoptar SCRUM es cómo hacer estimaciones y cómo nos van a ayudar éstas a saber qué tal vamos y cuándo vamos a finalizar el proyecto. En SCRUM suele estimarse dos veces (sí, dos veces) pero no en la forma tradicional con una única y sesuda estimación en horas/días de trabajo al principio del proyecto.

Esta forma de estimar suele traer algo de polémica pero intentaré explicarlo lo mejor que pueda: Haremos una primera estimación grosso modo en puntos y no en horas en la que partiendo de la lista inicial de funcionalidades a desarrollar estimaremos el esfuerzo o dificultad que supondrá realizar cada una de los requisitos del proyecto. Este esfuerzo lo mediremos o, mejor dicho, lo calibraremos en puntos siguiendo por ejemplo la serie de Fibonacci (1, 2, 3, 5, 8, 13, ...) o incluso usando las medidas usadas en las tallas de camiseta (S, M, L, XL, XXL, ...)

Si atendemos al concepto de Cono de Incertidumbre, hagamos la estimación que hagamos, le dediquemos el tiempo y metodología que queramos, nuestra estimación será errónea (a menos que conozcamos cada uno de los detalles del proyecto). Rodrigo Corral lo explica muy bien en Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil (el resto del post no tiene desperdicio tampoco) Entonces ¿por qué dedicar tanto esfuerzo? Asignemos 1 o 2 puntos a las funcionalidades sencillas, 3 o 5 a las de dificultad media y 8 o 13 a las de dificultad alta o muy alta (¿necesitas más puntos? quizás deberías descomponer esta funcionalidad en otras más pequeñas)

Esto traerá un considerable ahorro de esfuerzo al estimar y, por qué no, también quitamos estrés al equipo, que tendrá miedo a equivocarse. Con la estimación a alto nivel mediante puntos evitamos algunos de los inconvenientes de las estimaciones en horas: Si indicamos que en una tarea vamos a tardar 40 horas, la regla de que el trabajo se expandirá hasta tomar todo el tiempo disponible se aplicará a esto también. Por otra lado se evitará un fallo común en los que comienzan con SCRUM (sí, yo también lo cometí) y que consiste en pensar que "Si se ha trabajado 40 horas en esta tarea, el burndown graphic deberá bajar en 40 horas" Esto daría una falsa sensación de avance en el proyecto si la tarea no está completamente terminada y aprobada por el cliente.

La segunda estimación la haremos cuando planifiquemos las tareas del sprint. En esta planificación tendremos un mayor conocimiento del proyecto y de lo que implica cada tarea. Podríamos hacer entonces una planificación en horas aunque hay equipos que aún en ese momento usan una estimación en puntos o deciden no estimar en absoluto (ver entrada sobre técnicas de estimación en ScrumAlliance.org)

Estas estimaciones nos permitirán conocer el ROI (retorno de inversión) de cada funcionalidad para que el cliente pueda decidir qué tareas quiere realizar en el siguiente sprint y nos permitirá también, después de algunos sprints, conocer con bastante exactitud cuál es la velocidad del equipo

¿Medir las historias de usuario en puntos o en horas? Esta es la eterna pregunta que se realiza en el seno de un equipo scrum al comenzar a usar esta metodología. Los integrantes del equipo están acostumbrados a dar sus estimaciones en tiempo y les resulta extraño medir su esfuerzo en puntos.

Entonces, ¿Por qué medir las historias de usuario en puntos? En este post intentaré dar una explicación para que podáis convencer a vuestros compañeros de las virtudes de medir las historias en puntos.

En primer lugar uno de los puntos que la metodología basada en Scrum intenta resolver es poder dar un dato fiable de cuanto puede producir un equipo en el plazo delimitado de un sprint. Y este es un punto importante ya que el trabajo será realizado por el equipo y no por personas individuales. Si tenemos en un equipo tres pogramadores: un programador que calificaríamos como superior a la media, un programador senior y un programador júnior. Es de esperar que si asignamos la misma tarea a los tres programadores el tiempo para resolverla de cada uno será diferente, por ejemplo:

o El programador junior resolverá la tarea en H horas.o El programador senior resolverá la misma tarea en H/2 horas.o Y el programador experto resolverá dicha tarea en H/3 horas.

Cogiendo este ejemplo como premisa, cuando nuestro Product Owner asigne esta tarea al equipo deberemos gestionar las diferentes tareas asignándole una persona en concreto para poder dar una estimación clara de cuantas historias podremos realizar en un sprint. Obviamente esto supone un exceso de gestión que nos devuelve otra vez a las metodologías convencionales. Además nos obligará a asignar las tareas complejas siempre a las mismas personas y esto no ayudará a que el resto del equipo madure y coja confianza.

Bueno, ¿Y cómo nos olvidamos de las horas/hombre y empezamos a medir por puntos?. Empecemos por tener una escala de puntuación base para cualquier tarea. Normalmente se utiliza los puntos asignados en las cartas de poker planning. Los valores de estas cartas son: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 e infinito. Hay que tener en cuenta que la puntuación escogida además de darnos una aproximación de cuanto puede costar desarrollar una tarea también lleva un factor de incertidumbre que aumenta a medida que el número de puntos aumenta.

El valor 0 indica que una historia de usuario es muy simple y que puede estar realizada con un esfuerzo mínimo e infinito indica que la historia es tan compleja que no hay manera de saber cuanto se puede tardar en realizarla (en este caso la historia deberá ser troceada en historias más pequeñas con la finalidad de poder medirlas con más detalle)

El paso más adecuado para empezar a cambiar la forma en que medimos nuestro trabajo sería escoger una historia de usuario que todos consideremos como la más simple (por ejemplo realizar un formulario con tres campos) y preguntar a todos los miembros cuantos puntos de esfuerzo asignarían a esta tarea. El programador experto pensará "bueno esto lo puedo realizar en 3 horas", el programador senior pensará "seguro que necesito 4,5 horas para acabar la historia" y el programador júnior pensará "como mínimo necesito 9 horas para tener la historia terminada". Basándose en sus experiencias en horas intentaran hacer su primera

traducción a puntos de historia, después de alguna que otra discusión acordarán una puntuación para dicha historia, por ejemplo 2 puntos.

Bien, en ese momento ya tendremos una historia de referencia. Las siguientes historias podrán basarse en ella. El equipo podrá decidir si la siguiente historia es más o menos difícil que la historia que ya ha puntuado y asignarle una puntuación según la escala definida en las cartas de planning poker. Este proceso se irá realizando hasta que el equipo considere que no puede realizar más historias en un sprint. Llegado a este punto el equipo podrá decir cuantos puntos en total realizará durante el transcurso de dicho sprint.

¿Quiere decir esto que el equipo ya está en disposición de medir las historias en puntos? La respuesta es sí y no. Es un comienzo pero los resultados se irán viendo sprint tras sprint. A medida que el equipo vaya utilizando la metodología irá refinando su forma de puntuar las historias y dará una aproximación más certera en sus previsiones. No podemos esperar que el equipo acierte a la primera en sus predicciones pero con la confianza necesaria y el trabajo constante iremos viendo como el equipo evoluciona y progresa.

Con el tiempo la eterna pregunta ¿Pero que es un punto? irá desapareciendo de nuestros sprint planning. El equipo irá adaptando de una forma natural su forma de puntuar. En ese estadío podremos tener la certeza que cualquier historia de usuario será realizada por cualquier miembro del equipo y que el esfuerzo dedicado será el que el equipo puntuó en el momento de valorar la historia independientemente de quién la realice.

Estimar el tamaño de las historias con Puntos

Para ubicarnos: una historia es una funcionalidad que el Product Owner define (apoyándose en los interesados que corresponda) y prioriza en el Product Backlog para que el equipo la desarrolle. El Product Owner tiene la responsabilidad de que la historia esté correctamente definida y de aportar las explicaciones pertinentes para que el equipo la entienda. En este punto, la primera acción que realizará el equipo sobre cada historia es determinar su "tamaño" ya que este valor se utiliza para concretar el trabajo que se puede abordar en un Sprint.

A continuación vamos a exponer como realizar este proceso de estimación centrándonos en tres aspectos: la unidad de medida a utilizar, las limitaciones que ésta tiene y como realizar el proceso de estimación con el equipo.

Definimos un Punto de Historia de la siguiente manera:

1 punto de historia =

1 jornada de trabajo de un miembro del equipo en dedicación exclusiva

Es decir, si una historia tiene 3 puntos significa que si un miembro del equipo (solo uno) se dedica a trabajar para realizar la historia sin tener que dedicar tiempo a ninguna otra cuestión (ni reuniones, ni llamadas, ni "marrones" varios), necesitará 3 jornadas de trabajo.

Hasta aquí todo correcto, pero ...

La primera limitación es que estimar con Puntos de Historia es, por definición, impreciso: se basa en la premisa de que no hay interrupciones y no contempla la paralelización o colaboración en el trabajo. Sin embargo, el hecho de que olvidarnos de estos aspectos a la hora de estimar elimina las variables más complejas o indeterminadas y simplifica notablemente el proceso de estimación por parte de los miembros del equipo.

Solución: después de la estimación, cuando se procede a definir el Sprint Backlog, utilizaremos el "Cálculo de la Velocidad" del equipo definido por Scrum para hacer los ajustes que mitiguen esta inexactitud.

La segunda limitación vamos a ilustrarla con un ejemplo:

Disponemos de dos cajas con la misma forma y aspecto y que pesan 1 y 2 kilos. Sopongamos que te mandan coger las dos cajas, una en cada mano, y te preguntan cuál es la que más pesa. No te será difícil determinar cual es la caja de 2 kilos.

Ahora repetimos el experimento pero con otras dos cajas que pesan 11 y 12 kilos. En este caso te será más complicado determina cual es la más pesada, aunque la diferencia de peso entre las cajas en ambos experimentos es de 1 kilo.

Este ejemplo, trasladado a la estimación de historias, se traduce en que cuanto mayor es el tamaño de una historia, más difícil es determinar el número exacto de jornadas necesarias para completarla.

Solución: restringimos los valores a utilizar para estimar las historias a un conjunto de valores que se adapten a esta circunstancia. En este sentido hemos adaptado al modelo de Planning Poker en el que el conjunto de valores definido es el siguiente:

Esta serie es una adaptación de la sucesión de Fibonacci y que está ámpliamente extendida en Scrum, es más, existen aplicaciones móviles y barajas de cartas físicas con estos valores para ser utilizadas durante la estimación de las historias. Como podemos ver, a medida que avanzamos por la sucesión, el "salto" entre los valores disponibles cada vez es mayor. Además, la serie cuenta con un algunos valores especiales:

0, para estimar historias que ya están hechas o que son prácticamente inmediatas (se puede establecer un umbral mínimo, por ejemplo, las historias que impliquen menos de una hora de trabajo serán estimadas con un 0).

100, se reserva para historias abordables pero demasiado grandes, por lo que será necesario descomponer estas historias otras menores.

infinito, utilizado cuando las incertidumbres con respecto a la historia hacen que no sea estimable. Será necesario investigar antes de poder hacer una estimación de la misma.

?, cuando la persona que está realizando la estimación no cuenta dispone de los conocimientos o habilidades necesarias para abordar la historia.

¿Qué limite ponemos al tamaño de las historias?Nosotros tomamos como referencia la duración del Sprint: todas las historias deberán ser suficientemente pequeñas para que un solo miembro del equipo la pueda abordar durante el Sprint. Por ejemplo, si estamos planificando un Sprint con 15 días de trabajo efectivo, no deberíamos de manejar historias de más de 13 puntos. En caso de que una historia se estime por encima de este límite, intentaremos descomponerla en historias más pequeñas y manejables, siempre que sea posible.

La estimación se realiza generalmente durante el Planning. En este proceso, el Scrum Master repasa cada una de las historias priorizadas en el Product Backlog, confirma con el equipo que todo el mundo entiende los objetivos de la misma y lanza el proceso de estimación.

Cada miembro del equipo determina los puntos de historia que él considera oportunos. Es importante buscar un mecanismo que evite o minimice la influencia de la estimación de unos miembros en los demás. Por ejemplo, si se utilizan barajas de Planning Poker, cada miembro del equipo seleccionará la carta con su estimación y la dejará boca abajo sobre la mesa hasta que todos los demás hayan escogido una carta y, cuando todos la tengan, darán la vuelta a su carta de forma simultánea.

Si todos los miembros del equipo han realizado la misma estimación, estupendo, ya tenemos los puntos para la historia y podemos pasar a estimar la siguiente. Si hay discrepancias, se deberá de iniciar un debate en el que se justifiquen tanto los valores altos como los bajos. Después del debate, se repetirá la "votación" y este proceso se repite hasta llegar a un consenso. Es muy importante que el Scrum Master mantenga el debate correctamente orientado y que se esfuerce en facilitar el consenso y en que todo el mundo pueda exponer su opinión.

¿Cuántas historias estimar?Como mínimo hay que estimar historias suficientes para un Sprint, aunque lo ideal es dejar algunas más estimadas por si son necesarias para hacer ajustes con respecto al trabajo a abordar.

El cálculo de la velocidad

El objetivo del cálculo de la velocidad es determinar la capacidad de trabajo del equipo para un Sprint y, para este fin, se basa en la información recopilada de los Sprint anteriores.

La velocidad está relacionada con el método de estimación del tamaño de las historias.

Vamos a tratar los siguientes aspectos:

Calcular la velocidad real resultante del trabajo realizado por el equipo en el primer Sprint.

Interpretar correctamente el significado del valor obtenido. Utilizar este cálculo de velocidad durante el Planning del segundo Sprint. Conseguir el compromiso del equipo con el trabajo planificado para el segundo Sprint.

Y para ilustrar el cálculo y uso de la velocidad vamos a utilizar el siguiente ejemplo:

Tenemos un equipo de desarrollo compuesto por 4 miembros. La duración de los Sprints será de 15 jornadas de trabajo efectivo por Sprint. Las historias del Product Backlog están estimadas de la siguiente forma:

Historia Tamaño Historia TamañoH1 8 H7 2H2 13 H8 2H3 20 H9 13H4 3 H10 5H5 5 (*) H11 20H6 8 H12 5

(*) Esta estimación cambiará al inicio del segundo Sprint

Durante el primer Sprint, al no disponer de información de la capacidad de trabajo del equipo, se decidió intentar abordar las 5 primeras historias. Sin embargo, solo se han podido completar las 4 primeras. Además, durante el Sprint surgieron algunas incidencias que afectaron al equipo y que no estaban previstas: uno de los miembros del equipo estuvo un día de baja y todos los miembros del equipo tuvieron que asistir a un curso de un día de duración que no estaba programado al inicio del Sprint.

Calcular la velocidad real en un Sprint

Al final de un Sprint, la velocidad se calcula de la siguiente forma:

1. Total de puntos completados: se suman los puntos de historia correspondientes a las historias terminadas, es decir, de las 4 primeras (aunque el compromiso inicial fue de 5 historias, en realidad se completaron 4 y para el cálculo de velocidad solo se tiene en cuenta el trabajo finalizado).

Puntos completados = 8 (H1) + 13 (H2) + 20 (H3) + 3 (H4) = 44

2. Total de jornadas reales: se suman las jornadas reales que cada miembro del equipo ha realizado en el Sprint, descontando las ausencias o circunstancias especiales que han surgido.

Jornadas ideales = 15 + 15 + 15 + 15 = 60 Jornadas reales (descontando ausencias) = 13 + 14 + 14 + 14 = 55

3. Cálculo de Velocidad: la velocidad es la división de los puntos completados y de las jornadas reales.

Velocidad = 44 / 55 = 0,8 El equipo ha trabajado en el primer Sprint con una velocidad del 80%.

Interpretar el valor de la velocidad

Este es probablemente el aspecto más delicado del proceso. En las metodologías tradicionales estamos acostumbrados a que una jornada de trabajo equivale a 8 horas y a que los desarrolladores dedican todo ese tiempo a tareas de desarrollo. La experiencia suele demostrar que esta aproximación no es realista, todo el mundo tiene que atender eventos no planificados durante su jornada laboral. Algunos de estos eventos son: llamadas telefónicas o correos electrónicos, reuniones de seguimiento (en Scrum, la reunión diaria), ir al baño, corregir un bug grave que se ha descubierto...

Una velocidad del 80% significa que el equipo ha podido dedicar el 80% de su jornada laboral a acciones concretas de desarrollo que se habían programado para el Sprint y que un 20% ha sido invertido en otras acciones como las ya descritas. Al planificar los sucesivos Sprint con este "colchón" del 20%, estamos aportando al equipo una herramienta que le permite asumir trabajo no previsto sin que esto tenga impacto en el trabajo comprometido lo cual favorece el clima de trabajo y la imagen hacia el cliente.

Traducción de la velocidad horas de trabajo por díaExiste una tendencia en la que se mide la capacidad de trabajo de los equipos como el número de horas efectivas de trabajo por jornada, algo así como si mi jornada de trabajo es de "X" horas, se que tengo "Y" horas de trabajo efectivo y el resto es para tareas no controladas. A fin de cuentas, este cálculo es una particularización del cálculo de velocidad anterior: si un equipo tiene una velocidad del 75% y la jornada de trabajo es de 8 horas podemos decir que los miembros del equipo dedicas 6 horas al día a trabajo efectivo (75%) y 2 horas a tareas no programadas (25%).

¿Cuál es la medida de velocidad adecuada? Pues depende del equipo, del proyecto, de la empresa, etc. Generalizando mucho, un valor de velocidad del 80% es un dato muy bueno.

Utilizar la velocidad en el próximo Sprint

Ahora ya disponemos de un cálculo orientativo de la capacidad de trabajo del equipo y vamos a utilizarlo, siguiendo el ejemplo anterior, para determinar la cantidad de trabajo que el equipo podría asumir en el siguiente Sprint. Antes de planificar el Sprint debemos de tener en cuenta lo siguiente:

Durante el próximo Sprint 2 miembros del equipo estarán de vacaciones durante una semana cada uno (5 días).

La historia 5 estaba estimada en 5 puntos, pero como parte de esta historia fue abordada durante el primer Sprint (aunque no se completó), se realiza una re-estimación y se determina que su nuevo tamaño es de 2 puntos.

En el escenario descrito para el Sprint 2, vamos a proceder a determinar la capacidad de trabajo del equipo y a extrapolar este valor a las historias que podrán ser abordadas:

Jornadas de trabajo disponibles: determinamos las jornadas de trabajo para el nuevo Sprint como las suma de las jornadas que cada miembro del equipo podrá dedicar con la información de la que disponemos en este momento.

Jornadas previstas = 10 + 10 + 15 + 15 = 50 (descontando ausencias programadas)

Aplicar la velocidad: ajuste de las jornadas disponibles.

Puntos abordables = 80% de 50 = 40

Selección de historias potencialmente abordables: determinamos cuales de las historias podrán ser abordadas durante el Sprint en base a su prioridad, estimación y jornadas efectivas calculadas.

Suma de puntos de las historias H5 a H10 = 2 (*) + 8 + 2 + 2 + 13 + 5 = 32 (*) H5 re-estimada

Llegados a este punto tenemos un "problema" que solventar. Por una parte, si abordamos solo las historias de la H5 a la H10, al equipo le sobrarán 8 jornadas de trabajo real, lo cual es excesivo (semana y media de trabajo de un miembro del equipo o dos días no planificados para todo el equipo). Sin embargo, sin añadimos la siguiente historia en prioridad, la H11, la suma llega a 52, lo cual son 12 puntos por encima de las jornadas efectivas calculadas.

La solución depende del Product Owner, pero es el Scrum Master y el equipo quienes tienen que ayudarle a identificar las soluciones disponibles y a escoger la más razonable. Estas son algunas opciones:

o No respectar la prioridad, saltarse la historia H11 (20 puntos) y abordar en este Sprint la historia H12 (5 puntos), lo que suponen 37 puntos y es un valor razonablemente cercano a los 40 efectivos calculados.

o Dividir la historia H11 en varias historias más pequeñas, de forma que algunas de estas pueda ser abordada en el Sprint.

o Sustituir la historia H9 (13 puntos) por la H11 (20 puntos), lo que deja el total de puntos planificados en 39.

o Etc.

Conseguir el compromiso del equipo con el trabajo planificado para el segundo Sprint

Muy Importante: la velocidad y el trabajo propuesto a partir de este valor deben considerarse una referencia y solo tendrán validez si el equipo declara su compromiso para la realización del trabajo previsto. Es decir, según las circunstancias, para un Sprint la velocidad nos puede decir que tenemos capacidad para X jornadas, pero el trabajo final comprometido debe ser aquel con el que el equipo se sienta a gusto y con garantías de poder completarlo.

Esto supone que el equipo tendrá la libertad para reducir o aumentar la capacidad teórica de trabajo de un Sprint de forma justificada y dentro de unos límites razonables, con el fin de garantizar su compromiso con el trabajo programado.

Si este aspecto no se respeta, el equipo perderá confianza y buscará argucias para autoprotegerse de la imposición de trabajo excesivo... y la más sencilla la podéis ver en la siguiente tira: