¿Cómo decide el equipo qué historias incluir en el Sprint?
Utilizamos dos técnicas para esto:
- A ojo de buen cubero
- Cálculos de velocidad
Estimando a ojo de buen cubero
- ScrumMaster: “ A ver chicos, ¿podemos terminar la historia A en este Sprint?” (señala el elemento más importante de la Pila de Producto).
- Lisa: “Bah. Por supuesto que podemos. Tenemos tres semanas, y es una funcionalidad bastante trivial.”
- ScrumMaster; “Ok, ¿y si le añadimos la historia B?” (señala el segundo elemento más importante)
- Tom&Lisa al unísono: “Sigue siendo muy fácil.”
- ScrumMaster: “OK, ¿qué tal las historias A, B y C entonces?”
- Sam (al Dueño de Producto): “¿La historia C incluye manejo avanzado de errores?”
- Dueño de Producto: “No, no es necesario por ahora, podéis implementarlo con un manejo básico de errores.”
- Sam: “Entonces C podría entrar también.”
- ScrumMaster: “OK, ¿y si añadimos la historia D?”
- Lisa: “Hmmm…”
- Tom: “Creo que podríamos hacerlo.”
- ScrumMaster: “¿Seguro al 90%? ¿Al 50%?”
- Lisa y Tom: “Más bien al 90%.”
- ScrumMaster: “OK, D entra entonces. ¿Y si añadimos la historia E?”
- Sam: “Quizás.”
- ScrumMaster: “¿90%?¿50%?”
- Sam: “Yo diría que más cerca del 50%”.
- Lisa: “Tengo mis dudas.”
- ScrumMaster: “OK, entonces lo dejamos fuera. Nos comprometeremos a A, B, C y D. Por supuesto, terminaremos E si podemos, pero nadie debería contar con ello, así que lo dejamos fuera del plan de Sprint. ¿Qué tal así?”.
- Todo el mundo: “OK!”
Estimando usando cálculos de velocidad
Esta técnica consta de dos pasos
- Decidir la velocidad estimada
- Calcular cuántas historias se pueden añadir sin sobrepasar la velocidad estimada
La velocidad es una medida de “cantidad de trabajo realizado”, donde cada elemento se evalúa en función de su estimación inicial.
El siguiente gráfico muestra un ejemplo de velocidad estimada al principio de un Sprint y la velocidad real al final de dicho Sprint. Cada rectángulo es una historia, y el número interior es la estimación inicial de dicha historia.
Nota que la velocidad real esta basada en las estimaciones iniciales de cada historia. Cualquier actualización a la estimación de la historia realizada durante el Sprint es ignorada.
Ya puedo escuchar las objeciones: “¿Cómo va a ser esto útil? ¡Una velocidad alta o baja dependerá de un montón de factores! Programadores con poco sentido común, estimaciones iniciales incorrectas, cambios en el alcance, distracciones imprevistas durante el Sprint, etc.
Estoy de acuerdo en que se trata de un número bastante aproximado. Pero aun así es bastante útil, especialmente si lo comparamos con “nada en absoluto”. Te proporciona algunos verdades crudas: “sean cuales sean las razones, aquí está la diferencia aproximada entre cuánto pensábamos que podríamos hacer y cuánto hicimos en realidad”.
¿Qué pasa con las historias que casi se consiguieron durante el Sprint? ¿Por qué no conseguimos algunos puntos por ellas en la velocidad real? Bueno, esto es así para reforzar el hecho de que Scrum (y de hecho todo el Desarrollo Ágil de Software y Lean Manufacturing en general) gira en torno al concepto de conseguir que las cosas se hagan completamente, hasta un estado de “potencialmente entregable”. El valor de las cosas medio hechas es cero (podría de hecho ser negativo). Coged el libro de Donald Reinertsen “Managing the Design Factory” o uno de los libros de Poppendieck para aprender más sobre este concepto.
Así que, ¿mediante qué tipo de magia arcana estimamos la velocidad?
Una manera muy fácil de estimar la velocidad es revisar la historia del equipo.¿Cuál fue su velocidad durante los últimos Sprints? Y entonces asumir que la velocidad será más o menos la misma en el próximo Sprint.
Esta técnica se conoce como el tiempo que hizo ayer. Solo es factible para equipos que ya han hecho algunos Sprints (de forma que haya estadísticas disponibles) y que harán el próximo Sprint más o menos de la misma manera, con el mismo tamaño de equipo, las mismas condiciones de trabajo, etc. Este, claro está, no siempre es el caso.
Una forma más sofisticada de hacerlo es realizar un simple cálculo de recursos. Digamos que estamos planificando un Sprint de 3 semanas (15 días laborables) con un equipo de 4 personas. Lisa estará de vacaciones 2 días. Dave sólo estará disponible al 50% y estará un día de vacaciones. Poniéndolo todo junto…
…Tenemos 50 días-hombre disponibles en este Sprint.
¿Es esta nuestra velocidad estimada? ¡No! Porque nuestra unidad de estimación son puntos de historia lo que, en nuestro caso, corresponde más o menos a “días-hombre ideales”. Un día-hombre ideal es un día perfectamente efectivo, sin distracciones, lo cuál es raro. Lo que es más, debemos tener en cuenta cosas como trabajo no planificado que se añade al Sprint, gente que se pone enferma, etc.
Así que nuestra velocidad estimada será sin duda menor de 50. ¿Pero cuanto menor? Para esto usamos el “factor de dedicación”.
El factor de dedicación es una estimación de cómo de centrado va a estar el equipo. Un factor de dedicación bajo puede significar que el equipo espera encontrar muchas distracciones e impedimentos o que considera que sus propias estimaciones son optimistas.
La mejor manera de determinar un factor de dedicación razonable es estudiar el último Sprint (o incluso mejor, la media de los últimos Sprints).
La velocidad real es la suma de las estimaciones iniciales que se completaron en el último Sprint. Digamos que en el último Sprint se completaron 18 puntos de historia utilizando un equipo de 3 personas formado por Tom, Lisa y Sam trabajando las tres semanas hasta un total de 45 días-hombre. Y ahora estamos intentando calcular la velocidad del próximo Sprint. Para complicar las cosas, un nuevo tipo, Dave, se une al equipo para este Sprint. Teniendo en cuenta las vacaciones y demás asuntos tenemos 50 días-hombre ideales este Sprint.
Así que nuestra velocidad estimada para el próximo Sprint es de 20 puntos de historia. Eso significa que el equipo debe añadir historias al Sprint hasta que sume aproximadamente 20.
En este caso, el equipo puede escoger las 4 historias más importantes hasta un total de 19 puntos de historia, o las 5 historias más importantes hasta 24 puntos de historia. Digamos que escogen 4 historias, ya que se aproximan más a los 20 puntos de historia. Siempre que haya dudas, escoge añadir menos historias.
Dado que estas 4 historias suman 19 puntos, la velocidad estimada final para este Sprint es de 19.
“El tiempo que hizo ayer” es una técnica sencilla, pero úsala con cierta dosis de sentido común. Si el último Sprint fue especialmente malo porque la mayoría del equipo estuvo enfermo una semana, entonces podría ser adecuado asumir que no volverás a tener tan mala suerte y podrías estimar un factor de dedicación mayor el próximo Sprint. Si el equipo ha instalado recientemente un sistema super-rápido de compilación continua probablemente también podrás incrementar el factor de dedicación gracias a ello. Si una nueva persona se une a este Sprint deberías reducir su factor de dedicación para tener en cuenta su formación. Etc.
Siempre que sea posible, ten en cuenta varios Sprints y saca medias para conseguir estimaciones más acertadas.
¿Qué ocurre si el equipo es completamente Nuevo y no tienes ninguna estadística? Mira al factor de dedicación de otros equipos en circunstancias similares. ¿Qué pasa si no tienes otros equipos en los que fijarte? Adivina un factor de dedicación. Las buenas noticias son que sólo deberás adivinar para el primer Sprint. Después, tendrás estadísticas que podrás ir midiendo continuamente para aproximar mejor el factor de dedicación y la velocidad estimada.
El factor de dedicación “por defecto” que usamos para equipos nuevos es habitualmente el 70%, dado que es ahí donde terminan la mayoría de nuestros otros equipos con el tiempo.
¿Qué técnicas de estimación usamos?
He mencionado varias técnicas anteriormente – ojo de buen cubero, cálculo de velocidad basado en el tiempo que hizo ayer y cálculo de velocidad basado en días-hombre disponibles y factor de dedicación.
Así que, ¿qué técnica usamos?
Usualmente combinamos todas estas técnicas hasta cierto punto. Realmente no conlleva mucho esfuerzo.
Miramos el factor de dedicación y la velocidad real del último Sprint. Miramos al total de recursos disponibles para este Sprint y estimamos el factor de dedicación. Discutimos cualquier diferencia entre estos dos factores de dedicación y hacemos los ajustes que sean necesarios.
Una vez que tenemos la lista preliminar de historias a incluir en el Sprint hacemos un chequeo a “ojo de buen cubero”. Le pido al equipo que ignore los números por un momento y que piensen sobre si les parece un bocado realista como para zampárselo en un Sprint.
Si parece demasiado, quitamos una historia o dos. Y viceversa. Al final del día, el objetivo es simplemente decidir qué historias se incluyen en el Sprint. Factores de dedicación, disponibilidad de recursos y velocidad estimada son sólo medios para conseguir dicho objetivo.