Como estimamos proyectos Scrum o en general ágiles

Actualización: Este post es antiguo, después acabamos descubriendo mejores maneras de trabajar, y 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.

A casi todos los que conozcáis algo de agilidad o Scrum, os sonará lo del “planning poker”. A otros también os sonarán los puntos historia.  Bien. Pero de ahí a estimar… va un paso, un gran paso.

En este post os voy a contar cómo estimar usando técnicas de estimación ágiles (ya os he contado alguna vez que hay otras muchas maneras de estimar, que pueden funcionar en otros contextos). Os voy a contar unas cuantas maneras que yo he aplicado en proyectos ágiles (desde mi primer proyecto ágil del 2005 hemos aprendido mucho) y que he visto en otros tantos sitios que funcionan bien.

Las de aquí no son las únicas, no tienen porque funcionarte a ti, hay decenas de adaptaciones, pero creo que leerlas te puede dar muchas ideas. Por mi parte, dejarlas en este post es mi contribución a la comunidad, de la que no dejo de aprender viendo un proyecto y otro.

La estimación ágil se basa en el conocimiento, la experiencia.

La principal premisa en que se basa la estimación ágil es el conocimiento, la experiencia del propio equipo (frente a otros métodos de estimación que se basan en la experiencia de otros equipos, es decir, en la estadística). Bueno, muchos ya sabréis que por ejemplo Scrum se auto-denomina método empírico, y por ahí van los tiros.

Continuando con la base, hay dos parámetros fundamentales que vas a necesitar: la velocidad y cómo medir la cantidad de trabajo que hay que hacer (o que ya se ha hecho).

Para manejar los anteriores vas a necesitar una unidad de medida. Normalmente, se usan dos, una son las horas (y el trabajo realizado se medirá en horas), la otra son los puntos historia (un número que indica el tamaño del trabajo a realizar, o realizado, a número mayor trabajo más grande).

Yo os recomiendo utilizar los puntos historia.

La velocidad

La velocidad se calcula sumando el número de HU que se han convertido en working software (ojo, terminada, aquí sería importante que recuerdes aquel post de en un proyecto ágil, acordar una buena definición de lo que significa terminado (el done)) durante una iteración del proyecto (o sprint en terminología de la metodología Scrum). De la velocidad, ya hablamos en el libro Cómo sobrevivir… A la planificación de un proyecto ágil, te resumo del mismo:
– Si el equipo completó tres historias en la iteración, entonces su velocidad en esta iteración fue 3.
– Si el equipo completó dos historias su velocidad fue dos.
Si sumamos los puntos historia de todas las historias de usuario a desarrollar tendremos una estimación.

Iteración o Sprint

Velocidad

 

1

45

2

21

3

35

4

44

5

29

Tabla 1. Ejemplo de velocidad de un equipo

Estimando con Puntos Historia

Como has podido ver, el factor más importante es basarse en históricos, es decir, en la velocidad de los sprint previos. En el mundo Scrum a esto se le llama “Yesterday’s weather” (estimo el tiempo que hará hoy en base al que hizo ayer).

Hasta aquí, calcular la velocidad en función del Sprint anterior, o en base a una media de varios Sprint previos, como lo hicimos en la tabla anterior, funciona bien si el equipo es estable (cosa que debería ser), es decir siempre son las mismas personas y trabajan los mismos días, pero ¿qué pasa si varía el equipo o varía la dedicación?

La dura realidad dice que demasiadas veces no serán las mismas personas (alguien se pone enfermo, sale del proyecto o entra alguien más) ni se trabajan los mismos días en un Sprint que en otro (caen unos días de vacaciones por medio o simplemente en un Sprint la gente está más dedicada al proyecto que en otro).

Para ello usamos el factor de disponibilidad y las reglas de tres (esas que nos enseñaban en el cole). Vamos a verlo con un ejemplo, que te lo voy a explicar con la tabla de abajo, que es el Excel que yo uso (Henrik Kniberg comenta un método similar en Scrum and Xp from the Trenches, pero en mi opinión se entiende peor que el siguiente).

El Sprint 3 terminó, hicimos 40 puntos historia (columna A) con 80% de disponibilidad (columna C). De 150 horas máximo que se podría haber trabajado en el Sprint 3 (columna B) realmente se trabajó en el proyecto un 80%, es decir, 120 (columna D), no se hicieron 150 porque una persona se puso enferma, hubo que atender otras cosas, etc. Es decir, que de media cada hora de trabajo produjo 0,3333 puntos historia (columna E).

  A B C D E
  Puntos Historia Completados(D*E) Horas  – Hombre Ideales(días laborales del Sprint * Número de Personas en el  equipo Disponibilidad (tiempo que realmente dedicaron al proyecto) Horas realmente dedicadas al proyecto (las que lograron los puntos historia que se completaron) (B * C) Así que, cada hora se hizo este número de puntos función…A/D
Sprint 3 40 150 80% 120 0,33333

Ahora queremos estimar el Sprint 4. Si fuese todo perfecto podríamos trabajar, viendo el calendario, idealmente 200 horas (columna B). Pero por vacaciones sabemos que la disponibilidad va a ser del 50% (columna C), es decir 100 horas (columna D).
Vamos a suponer que se realizarán en este Sprint el mismo número de puntos historia por hora que en el anterior (columna E), así que multiplicamos las horas que previsiblemente se trabajará (columna D) por la previsión de puntos historia (columna E), obteniendo los puntos historia totales previstos a completar (columna A).

  A B C D E
  Puntos Historia Estimados(D*E) Horas  – Hombre Ideales(días laborales del Sprint * Número de Personas en el  equipo Disponibilidad (tiempo que vemos que se dedicará al proyecto) Horas realmente dedicadas al proyecto (B * C) En el Sprint anterior, cada hora se hizo este número de puntos función…A/D
Sprint 4 33,3 200 50% 100 0,33333

En cualquier caso, la experiencia, lo que se recomienda, es que la disponibilidad de tiempo no supere el 80% (columna C) dejando el resto para imprevistos o para mejoras. Este tema, además, el del 80%, cuando estuve con Jeff Sutherland (creador de Scrum) en Estocolmo, nos lo recomendó explícitamente, le llaman patron de «equipos que terminan antes aceleran más rápido».

Cosas que puedes leer para ampliar lo anterior sobre estimación ágil

Estos temas, complementarios y relacionados los puedes encontrar en el libro Cómo sobrevivir… A la planificación de un proyecto ágil.
Te recomiendo leer el libro de Henrik Kniberg, Scrum and Xp from the Trenches (Enterprise Software Development), que trata muchos de los anteriores conceptos.

10 comentarios en “Como estimamos proyectos Scrum o en general ágiles”

  1. Pingback: Bitacoras.com

  2. Pedro L. García Repetto

    Javier, a pesar de los muchos post que leo de tu blog me sigues sorprendiendo con los contenidos, propuestas y temas interesante. El de hoy hace referencia a la estimación que como bien indicas en un post anterior no es privativa de nuestro campo de acción.
    Reconocimiento la calidad e importancia del contenido de este post, sólamente un pequeño detalle: quizás fuese conveniente sustituir la expresión «Horas – Hombre » por «Horas – Persona «.
    Gracias y empiezo a esperar el post de mañana … Pedro

  3. Muy interesante el Post Javier. La verdad que los temas de estimación, bien sea en el entorno ágil o el tradicional, son un verdadero dolor de cabeza. Yo creo que lo primordial es saber distinguir entre objetivos de negocio y compromisos. No todo objetivo de negocio deseable debe devengarse en compromiso: No se puede construir una catedral en dos día con un martillo y un trabajador, por más deseable que para el futuro dueño de la catedral esto sea.
    En mi experiencia, en entornos ágiles me ha funcionado lo siguiente, que además propongo en mi trabajo de grado y en mi libro:
    Es una combinación de tres de las técnicas más utilizadas en esta área: juicio experto por analogía, estadísticas de la velocidad del equipo y juicio experto por analogía mediante el método Delphi, este último con la metáfora del popular juego de «Planning Poker».
    La idea es usar las tres técnicas y colocarle un peso(tal como cuando sacamos la esperanza matemática de algo). Supongamos que el juicio experto de lider es 20 puntos la historia, que el juicio del equipo, tras el planning poker es 15puntos la historia y, por último, supongamos que la velocidad del equipo promedio por historia son 11 puntos.
    Supongamos además, que se se ha asignado los siguientes pesos a las estimaciones:
    Juicio experto: 20%
    Planning Poker: 40%
    Estadísticas de Velocidad del equipo: 40%
    El resultado final para esta historia sería: 20%(20) + 40%(15) + 40%(11) ; es decir 14
    Entonces el punto para esa historia sería 14. Y se a tomado en cuenta al líder, al equipo y las estadísticas.
    Creo que aunque esto no es ni mucho menos la panacea, ni se pueden resolver todos los casos con esta técnica, lo cierto es que me ha funcionado en distintos proyectos y en distintas organizaciones.
    Espero que les sea de utilidad,
    Saludos

  4. Un post estupendo Javier.
    Mi experiencia me dicta que el factor que has definido como «disponibilidad» debe estar ligado a las circunstancias del proyecto.
    Utilizo un sistema parecido para hacer mis estimaciones y la disponibilidad suelo contemplarla como una variable en la que juegan un papel crucial la incorporación de nuevo personal y el grado de incertidumbre de la fase del proyecto.
    Respecto al personal, suelo establecer una curva de aprendizaje en la que la productividad de un nuevo componente del equipo empieza siendo negativa (los compañeros tienen que ayudarle). Es una forma de explicar el porque incorporar gente nueva no significa necesariamente completar antes el proyecto.
    Respecto al grado de incertidumbre, desgraciadamente la indefinición es un factor demasiado frecuente en los entornos tipo startup. Medir la indefinición y considerarla un atenuador de la disponibilidad me ha ayudado en ocasiones a justificar demoras en los tiempos de entrega. Considero que tener en cuenta los cambios de opinión en determinados proyectos es realmente importante.
    Tienes un blog maravilloso Javier, es una gran suerte haberlo encontrado.
    Un saludo.

  5. Una sugerencia que me gustaria compartir en terminos de estimacion es que no solo considereis la disponibilidad de un miembro del equipo sino tambien factorizar el nivel de experiencia en la tecnologia utilizada. En mi experiencia esto me ha ayudado a ajustar mis estamaciones en terminos de capacidad de «quemar» story points.
    He incluido un ejemplo donde podeis ver como considero dias disponibles cada semana, focus y nivel de experiencia.
    Resource Proficiency Focus w1 w2 w3 w4
    Pepito 60% 100% 5 5 5 5 ] 12
    Mike 90% 100% 5 5 5 5 ] 18
    Raffaele 50% 90% 5 5 5 5 ] 9
    Lucas 90% 100% 5 5 5 5 ] 18
    Jezz 100% 50% 5 5 5 5 ] 10
    Effectiveness: 67
    Raff

  6. Hola Javier, muy buen post y excelente blog. Desde que lo leo he encontrado buenas respuestas a mis preguntas sobre desarrollo ágil y sobre scrum específicamente.
    Ahora tengo una pregunta. Estas estimaciones se basan en estadísticas sobre el trabajo con el mismo equipo en un proyecto. Sin embargo, todavía tengo la duda de cómo estimar la duración de un proyecto con un equipo que no conoces.
    En este momento tengo un posible cliente que me pide una oferta para desarrollar un proyecto. Pero en la oferta debo estimar el tiempo del proyecto pues es una variable a tener en cuenta en los honorarios. El equipo lo estamos formando, entre desarrolladores de la propia empresa del cliente y nuestros. Con métodos tradicionales podemos hacerlo, aunque sabemos que la realidad puede ser otra, sin embargo, en un entorno ágil no tengo idea de cómo hacerle una estimación en la que yo mismo pueda confiar.
    Saludos y gracias de antemano.

Deja un comentario

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

Share This
Ir arriba