Mi equipo está adoptando Scrum. Al estimar los puntos de la historia para un elemento pendiente, utilizamos el póquer de planificación para reflejar la visión promedio del equipo sobre la complejidad de la historia.
Al estimar las horas de tareas dentro de una historia, ¿debemos planificar en función de la capacidad de la persona que ejecuta la tarea o de la capacidad promedio del equipo? ¿Qué pasa si alguien más lento asume esa tarea? ¿Deberíamos entonces volver a estimar el trabajo restante?
Debe equilibrar dos necesidades contrapuestas en la gestión de proyectos: la necesidad de precisión y la necesidad de flexibilidad.
Como siempre, la realidad es específica a su situación. Usted, como PM, debe usar su juicio sobre la probabilidad de que otro desarrollador se haga cargo de una tarea una vez que se le haya asignado, luego use el método de cálculo de horas más apropiado. Esta decisión también puede depender de sus clientes/partes interesadas y sus requisitos de precisión frente a flexibilidad.
Mi sugerencia es elegir un método e ir con él. Revise la precisión de las estimaciones en los próximos sprints y calcule su eficacia, luego ajuste sus métodos según sea necesario.
Si tiene un cliente que insiste en este tema, simplemente indique su metodología y su plan de ajuste. Una buena gestión de proyectos se trata de tomar una decisión oportuna e implementarla y luego revisar los efectos de la decisión y hacer los ajustes necesarios. (En realidad nunca termina........)
Es probable que los problemas de su proceso sean el resultado de los siguientes errores de implementación de Scrum:
No hagas esas cosas. Estime historias de forma colaborativa y cronometre sus historias y tareas en lugar de perder tiempo en la quimera de la precisión del nivel de tareas.
Ha creado una falsa dicotomía entre la estimación y el desempeño de la tarea. Cuando preguntas:
Al estimar las horas de tareas dentro de una historia, ¿debemos planificar en función de la capacidad de la persona que ejecuta la tarea o de la capacidad promedio del equipo?
está violando varios principios interconectados de implementaciones efectivas de Scrum. Específicamente:
En otras palabras, el problema subyacente es que está tratando la estimación como una actividad de equipo, pero el desempeño de la tarea como una actividad individual. No hagas eso.
También está creando una comparación falsa con sus prácticas de estimación. Por lo general, los equipos estiman en colaboración los elementos de la cartera de productos (PBI), como las historias de los usuarios, pero los equipos de Scrum efectivos rara vez descomponen las historias en menos de medio día y, por lo general, no estiman las tareas en absoluto.
Si bien puede encontrar cierto apoyo en la literatura para estimar las tareas de PBI en horas ideales, hacerlo suele ser ortogonal a la estimación ágil, que se basa en promedios estadísticos a lo largo del tiempo en lugar de un nivel de precisión artificial (y a menudo engañoso). ¿Puede realmente pronosticar la mayoría de las tareas impulsadas por humanos con la precisión suficiente para justificar la sobrecarga de estimarlas individualmente? En el mundo del software, al menos, la respuesta suele ser "no".
En general, debe jugar al póquer de planificación (o usar alguna otra técnica de estimación del equipo) en las historias de los usuarios. Dado que las historias se hacen o no se hacen , rara vez vale la pena estimar las tareas, y casi nunca como grupo.
En el raro caso extremo en el que hay algún tipo de valor en la estimación de tareas individuales, debe aprovechar la reunión diaria para permitir que el equipo coordine las tareas dentro de un cuadro de tiempo de 1-2 días. Algunos ejemplos de esta coordinación son:
Concéntrese en hacer que las historias se hagan a un ritmo sostenible, en lugar de si las estimaciones específicas del nivel de tarea son precisas con dos decimales. Cuando se hace correctamente, esto generalmente mejorará la precisión general de su proceso de estimación, por contradictorio que parezca. E incluso si no mejora la precisión, al menos no pasará una cantidad excesiva de tiempo tratando de asignar un nivel falible de precisión a las cosas.
Cuando hagas la planificación, es mejor ir con el promedio del equipo. Cuando la tarea es propiedad de cada individuo, debe resolverse.
Otra perspectiva es que, para el equipo también, no puede haber una gran diferencia entre el promedio individual + del equipo. Si es así, definitivamente habrá otros gastos generales como problemas de actitud, etc. Cuando hay un hiperactivo, también habrá totalmente opuesto a eso en el equipo.
¿Qué sabemos acerca de la estimación del tiempo? Es intrínsecamente inexacto para el trabajo cognitivo complejo, independientemente del método que se utilice. De ahí la preferencia por el tamaño relativo. Las estimaciones son realmente las mejores conjeturas. Lo que realmente importa son los datos empíricos que se pueden recopilar una vez finalizado el trabajo.
El progreso de Sprint Backlog se puede medir mediante varios métodos. Mientras la comprensión de cómo se mide el progreso hacia el Sprint Goal sea transparente, no importa qué unidades de medida se utilicen. Algunas alternativas son la cantidad de tareas, las estimaciones de elementos de la Lista de Producto, la cantidad de elementos de la Lista de Sprint.
Independientemente del método, el equipo de desarrollo realiza una estimación inicial. A medida que un miembro del equipo de desarrollo selecciona cada tarea y a lo largo del Sprint, ese valor debe actualizarse para medir el progreso hacia el objetivo del Sprint. Después de todo, ese es su propósito.
Barnaby dorado