Tengo cierta confusión con respecto al concepto de estimación de la tarea de una historia de usuario (estimación de esfuerzo) usando horas. ¿Cuál es el propósito real de estimar el esfuerzo en horas?
Además de eso, digamos que la velocidad de mi equipo es de 50 puntos de historia y la duración de nuestro Sprint es de 2 semanas. En la reunión de planificación de Sprint, hemos extraído 50 puntos de historias de usuarios para el Sprint Backlog. Luego comenzamos a dividir las historias de usuario en tareas y estimar el esfuerzo usando horas. Luego, hemos notado que el total de horas de todas las tareas (para todas las historias de usuario) es de 2,5 semanas. En esta situación, la estimación de la tarea (estimación del esfuerzo) está en conflicto con la velocidad. Entonces, ¿cómo superamos esto?
No es necesario estimar usando puntos de historia a nivel de historia y tiempo a nivel de tarea, pero puede ser útil, particularmente para equipos que son nuevos en Scrum.
Algunas razones para usar estimaciones de tareas basadas en el tiempo incluyen:
Muchos equipos de Scrum experimentados encuentran que los gastos generales de hacer las estimaciones del nivel de tarea no valen los beneficios. Sin embargo, para los equipos más nuevos puede ser un buen paso de transición lejos de un enfoque de estimación más tradicional.
Para responder a su primera pregunta sobre: el propósito de estimar el esfuerzo en horas, es realmente más complejo que simplemente tiempo/elemento. Estamos tratando con personas aquí, y las personas tienen diferentes conjuntos de habilidades, velocidades y conocimientos. Si usa horas, oculta la razón principal para usar puntos de historia en primer lugar, que es permitir que los miembros del equipo que se desempeñan a diferentes velocidades se comuniquen y estimen en colaboración.
Siendo práctico, tres desarrolladores pueden comenzar estimando una historia de usuario determinada como 5 puntos, incluso si sus estimaciones individuales del tiempo real en la tarea difieren. A partir de esa estimación, pueden acordar estimar algo como 3 puntos, relativamente hablando de los criterios de trabajo que todo el equipo ya ha completado. Cuando los puntos de la historia equivalen a horas, los miembros del equipo ya no pueden hacer esto.
En este escenario, los puntos de la historia siguen teniendo que ver con el esfuerzo, pero la cantidad de tiempo por punto no está vinculada a la misma cantidad para todos los miembros del equipo. Los puntos de la historia permiten estimaciones relativas colaborativas sin la necesidad de tener en cuenta el tiempo de cada desarrollador individual para completar la tarea.
Para responder a su segunda pregunta, recomiendo NO planificar todo el sprint en Sprint Planning. Recomiendo especialmente no prestar atención a las horas/artículo. En su lugar, concéntrese primero en los elementos de mayor valor y, a medida que surjan los requisitos, intégrelos en el sprint si ayudan a su equipo a lograr su objetivo de sprint. Use sus métricas para ayudar a pronosticar su esfuerzo. No es necesario planificar todo el sprint en Sprint Planning, pero debe comprender cómo el trabajo que ha realizado su equipo los llevará a su objetivo. Entregar valor siempre debe ser más importante que comprender qué tan precisos son sus pronósticos de sprint a sprint. Eso no significa que las estimaciones precisas no sean importantes, pero ofrecer valor debe ser el enfoque principal.
Finalmente, entendí algunos beneficios de la estimación de tareas usando horas y cómo superar mi segunda pregunta.
Según tengo entendido, dividir las historias de usuario en tareas es beneficioso para comprender "cuánto trabajo puede realizar el equipo para un Sprint", si no conocemos la velocidad del equipo. Sin embargo, antes de estimar las tareas, el Scrum Master (SM) debe preparar la planificación de la capacidad de un equipo para comprender cuál es el máximo/total de horas de trabajo que tendrán los miembros individuales en el Sprint.
Después de eso, en Sprint Planning, el equipo puede dividir las historias de usuario en tareas y el SM puede facilitar el seguimiento de los compromisos de tareas individuales frente a la capacidad total de una persona individual. Si un miembro excede la capacidad total, el SM debe informar al Equipo. De esta forma, podemos evitar la sobrecarga o subcarga de un miembro del Equipo dentro del Sprint.
Una vez que todos los miembros del equipo se han comprometido con las tareas con toda su capacidad, podemos identificar la velocidad calculando las historias de usuarios comprometidas. Sin embargo, si el equipo es lo suficientemente maduro como para estimar el uso de puntos de historia de usuario y conocemos la velocidad promedio (después de ejecutar más de 4 sprints), entonces no hay necesidad de dividir las historias en tareas, a menos que la empresa use compromisos individuales como su evaluación anual Rendimiento clave Indicadores.
Para evitar exceder la duración del Sprint, el SM debe preparar una planificación de la capacidad antes del compromiso de la tarea individual. El SM debe monitorear la capacidad de cada miembro individual del Equipo examinando su capacidad total para que el Equipo no exceda la duración del Sprint con la estimación. Sin embargo, en este método, no podemos llevar las historias de los usuarios a Sprint Backlog considerando la velocidad, luego dividirlas en tareas y nuevamente estimar el uso de horas. O tenemos que sacar historias considerando la velocidad o tenemos que sacar historias usando la capacidad del Equipo.
Pesil