Después de un par de post "teóricos" vamos a empezar con cuestiones prácticas. Uno de los aspectos que más quebraderos de cabeza nos dio al empezar a trabajar con Scrum fueron las estimaciones de las historias. Hemos probado varios mecanismos y, por fin, hemos encontrado uno que resulta manejable, útil y satisfactorio.
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.
La unidad de medida: Puntos de Historia
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 ...
Limitaciones del uso de Puntos de Historia y cómo solucionarlas
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.
El proceso de estimación
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.
Espero que este sistema os sea tan útil como a nosotros.
7 comentarios:
Enhorabuena por el articulo Diego. El único pero que le pondría es el tema de asignar 1 punto historia a 1 día de trabajo, eso significa que realmente estas estimando en tiempo y no realmente utilizando puntos historia.
Yo soy partidario de establecer 1 punto de historia o tarea (depende de si se planifican historias o tareas de una historia) y a continuación comenzar a estimar mediante Planning Poker por similitud en esfuerzo.
Cuando se termine el primer sprint se obtiene la velocidad estimada en puntos historias.
Si establecer 1 punto = 1 día/persona, entonces se esta influenciando al equipo a realizar un numero determinado de puntos por sprint de forma obligatoria, p.e. un equipo de 7 personas en un sprint de 3 semanas (15 días) tendrían que realizar 7 x 3 x 15 = 315 puntos historia.
Salu2. Héctor.
Perdón serian 15 días x 7 personas = 105 puntos por sprint y por tanto esa seria la velocidad del equipo.
Sin embargo si estimamos por:
1.- 1 punto = ¿Historia o Tarea que requiere menor esfuerzo?
2.- A continuación estimar por similitud (Esfuerzo), daremos 2 puntos si es el doble, 3 el triple etc mediante Planning Poker.
3.- Prioridad
4.- Longitud de la Iteracion
5.- Velocidad Estimada de la Iteracion.
Si se han realizado 50 puntos en el primer sprint, 60 en el segundo en el tercero podemos estimar que vamos a hacer 55 puntos hasta que encontremos la velocidad del equipo.
De nuevo enhorabuena por tu articulo.
Salu2. Héctor.
Hola Héctor, antes de nada, muchas gracias por tu comentario.
Soy consciente de esta limitación que planteas, pero intentamos mitigarla haciendo uso de la velocidad. Si te es posible, te invito a leer el siguiente post de este blog en el que se trata este tema.
Resumiendo mucho, nosotros lo que hacemos es contabilizar el número de jornadas disponibles (siguiendo tu ejemplo 105) y aplicamos la velocidad para "ajustar" este dato. Si por ejemplo la velocidad es del 75%, aplicado a las 105 jornadas, tendríamos que podemos abordar unos 78 puntos en el próximo Sprint.
Este mecanismo no es perfecto pero tiene dos ventajas: es una unidad de medida invariable en el tiempo (no depende del conjunto de historias ni de la experiencia) y es muy fácil determinar los puntos previstos para un Sprint contabilizando ausencias o dedicaciones parciales de los miembros del equipo, porque partimos de las jornadas disponibles.
El sistema que propones ya lo conocía, pero se nos planteaba un problema a la hora de aplicarlo que quizá puedas ayudarme a solventar:
¿Cuándo se escoge la historia de referencia? ¿Al inicio del proyecto, para cada Sprint?
Si se escoge al inicio del proyecto, a medida que los miembros del equipo se familiarizan más con el proyecto esa referencia deja de ser buena (al saber más, necesitaría menos tiempo para ese trabajo) y aparentemente provocaría que en cada Sprint se pudiese sacar adelante más trabajo (la unidad de referencia se hace "más pequeña").
Si se escoge para cada Sprint el valor ese valor de 1 punto no es estable, porque el esfuerzo necesario para cubrir la más pequeña de las historias puede variar notablemente entre Sprints y entiendo que esto desvirtuaría el valor de la velocidad.
Hola Diego,
Efectivamente se elige en el primer sprint y debe ser una tarea pequeña que sirve de referencia. Como bien indicas el equipo según avanza el proyecto tiene más experiencia y por tanto debe realizar más puntos. Esto expresa de forma factible que las cosas se están haciendo cada vez mejor, por eso te indicaba el tema de la velocidad estimada que debe ir variando durante el proyecto.
Además que el equipo haga cada vez más punto es una forma de que no disminuya la motivación del equipo y que no se relaje.
No obstante, si esta forma de estimar y planificar os funciona pues no la cambies, el problema es cuando planificas 80 puntos y se hace 50.
Muchas gracias y ya tienes un seguidor más de tu web. :)
Salu2. Héctor.
Gracias Héctor, tomo nota de este mecanismo que me propones y, si tengo oportunidad, intentaré ponerlo en práctica para para poder comparar ambos sistemas.
Un saludo.
Excelente, no encontré explicación similar en otro sitio
Gracias Alejandro. Ten en cuenta que este es un mecanismo de estimación que, desde el punto de vista de un Scrum "purista", está anticuado.
Recientemwnte he hecho una nueva certificación de Scrum y la tendencia actual está orientada a realizar estimaciones relativas, no vinculadas al tiempo, por comparación de historias. Tengo previstos un par de post sobre estos temas.
De todas formas, aunque no sea un mecanismo purista, si te es útil (yo hay proyectos en los que lo sigo aplicando), adelante con ello.
Un saludo.
Publicar un comentario