Este es un tema alrededor del cual suele producirse confusión. Aunque lo que estimamos es esfuerzo y no tiempo, la unidad "horas ideales" la asociamos inconscientemente al tiempo.
Para ilustrarlo veamos el siguiente ejemplo: Un historia de usuario estimada en 20 horas se ha descompuesto en la reunión de planificación del sprint en una tarea de 8, otra de 10 y otra de 4 horas. Sumando las tareas vemos que necesitaremos 22 horas, y suponiendo que solo realizamos esa historia de usuario en ese sprint, nos preguntamos si la velocidad del equipo es 20 o 22.
Fijaros que la estimación de la historia de usuario probablemente la hayamos realizado en unos pocos minutos, seguramente con estimación de póquer, mientras que las estimaciones de las tareas las hemos trabajado y pensado en profundidad. Simplemente no podemos comparar unas horas con las otras, sería como comparar manzanas con peras.
Por tanto la velocidad del ejemplo anterior es 20h/sprint, aunque se estimen 22 horas ideales para desarrollar las tareas.
Ahora cambiamos de escenario, en vez de la estimación de 20 horas, estimamos la historia de usuario en 5 puntos de historia. ¿A que ahora no hay duda de que la velocidad es de 5 puntos de historia/sprint? Recordad que las tareas de la pila de sprint siempre se estiman en horas, por tanto aquí tenemos una buena razón para medir el esfuerzo de la pila de producto en una unidad diferente a horas.
Las consecuencias de confusión en este tema pueden ser nefastas para un proyecto. Nuestra historia tiene un tamaño en esfuerzo de 20 horas, como hay cierta confusión pensamos que nuestra velocidad es de 22 horas/sprint, y por tanto cuando hagamos la siguiente reunión de planificación de sprint seleccionaremos historias por esas 22 horas... cuando realmente nuestra velocidad en horas de pila de producto es de 20. Tomaríamos la decisión equivocada de incluir la historia 3 del ejemplo anterior en el segundo sprint. La buena noticia es que al cabo de 2/3 sprints cualquier equipo se daría cuenta de ello y tomaría las medidas adecuadas.
Recordad, la velocidad siempre se ha de basar en, y solo en, las estimaciones de la pila de producto.
Para aquellos interesados en Scrum, Kanban, Marcos de Escalado y Agilidad les cuento en este blog
mis experiencias, mis historias y mis anécdotas, tanto como coach de equipos y empresas, como de trainer de cursos.
Piensa dos veces, hazlo bien a la primera, aprende a acabar las cosas importantes al 100% con un ritmo bisemanal.
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario