Soy un nuevo maestro de scrum para un equipo que usa estimación de puntos de historia y horas. Hacemos puntos de la historia primero durante el aseo y luego horas durante la planificación.
Siempre pensé que los puntos de la historia eran principalmente para el director del proyecto y las horas para los ingenieros (esa era simplemente la forma en que habíamos estado haciendo las cosas). Un compañero de trabajo y compañero ingeniero preguntó por qué usamos ambos.
Mientras leo artículos como: No equipare los puntos de la historia con las horas , que explica por qué no debe usar los puntos de la historia con las horas aunque estén relacionados O ¿Hay alguna investigación publicada sobre los puntos de la historia frente a la estimación del tiempo? lo que explica que los puntos de la historia son más precisos para la estimación.
No veo mucho escrito sobre el uso de ambos. Estimamos historias por puntos de la historia, lo que nos da un sentido amplio, y luego desglosamos cuánto durará cada tarea y usamos los puntos de la historia y las horas para darnos una estimación. Empiezo a preguntarme sin embargo si mi compañero de trabajo está en algo.
¿Usar Story Points y horas es una cosa? ¿Hay algún consejo a favor o en contra? Reconozco que probablemente tome 2 horas adicionales hacer ambas cosas (multiplicado por cada miembro del equipo) y cuesta mucho.
¿Por qué usar ambos? ¿Alguien tiene alguna experiencia con esto?
La estimación de puntos de historia y la estimación de horas tienen diferentes propósitos.
Utilizamos Story Points durante el refinamiento de la cartera de productos.
Los Story Points son buenos para la planificación de alto nivel.
Cuando hacemos una estimación en Story Points hablamos de la productividad de todo el equipo . Durante la planificación de alto nivel, lo único que importa es la productividad de todo el equipo.
La estimación de puntos de historia es una medida relativa . Es muy conveniente para la planificación de alto nivel. Si el equipo aumenta su productividad (mediante el uso de CI, por ejemplo), entonces el equipo pronosticará más SP en el próximo Sprint. En el caso de la estimación de horas, el equipo debe volver a estimar (y reducir las horas necesarias) todo el Product Backlog.
Usamos Horas durante la Planificación de Sprint.
Las horas son buenas para la planificación de bajo nivel.
Cuando hacemos una estimación en horas hablamos de la productividad de Desarrolladores concretos . Es imposible usar SP para tareas de planificación de desarrolladores específicos, porque (como dije antes) los SP son para medir relativos. Un desarrollador puede implementar 1 SP en 1 hora, otro puede implementarlo en 2 horas.
La estimación de horas es una medida absoluta . Es muy conveniente para la planificación de bajo nivel. Siempre tiene 160 horas de trabajo en un mes, y la productividad del equipo no puede aumentar o disminuir en gran medida durante este breve período.
Entonces, es por eso que estimamos los elementos de la cartera de productos en puntos de historia y tareas (en los que descomponemos los BPI) en horas.
¿Usar Story Points y horas es una cosa? ¿Hay algún consejo a favor o en contra? ¿Por qué usar ambos? ¿Alguien tiene alguna experiencia con esto?
Digamos que la velocidad promedio de su equipo (en los últimos 3 o más sprints) es de 30 puntos de historia. Digamos que ha fluctuado entre 27 y 32. Para el próximo sprint, ¿pronostican ustedes como equipo 30 puntos (el promedio), 27 puntos (conservador) o 32 puntos (optimista)? No hay una forma objetiva de determinar eso. Tienes que tener en cuenta todas las tareas de grupo y las vacaciones, vacaciones, etc. de los miembros del equipo.
En cualquier caso, durante la planificación de Sprint, está haciendo una planificación más detallada al profundizar en cómo va a implementar la historia mediante la identificación de las tareas individuales. Estimar horas no debería ser demasiado esfuerzo adicional. Le ayuda a poner su previsión de Sprint de historias sobre una base mucho más firme.
No veo mucho escrito sobre el uso de ambos.
La analogía de Mike Cohn de un equipo de baloncesto es probablemente más fácil de entender: Supongamos que un equipo de baloncesto está en la mitad de su temporada. Han anotado un promedio de 98 puntos por juego en los 41 juegos hasta el momento. Sería apropiado que dijeran "Promediaremos 98 puntos por partido el resto de la temporada". Pero no deberían decir antes de ningún juego: “Nuestro promedio es 98, por lo tanto, anotaremos 98 esta noche”. Por eso digo que la velocidad es un predictor útil a largo plazo, pero no es un predictor útil a corto plazo.
También puede leer su artículo más reciente sobre este mismo tema:
Por qué los sprints deben planificarse con horas, no con puntos
Ambos artículos tienen buenos hilos de comentarios con más aclaraciones de Mike.
Hay dos razones por las que he visto que los grupos usan puntos de la historia y horas:
1) Alguien simplemente no puede dejarlo ir. Por lo general, alguien es un PM o un gerente y no puede renunciar a la especificidad de las horas, independientemente de cuán precisas puedan ser o no. Esto, por supuesto, no es una buena razón para hacerlo, de hecho es muy mala, pero es mejor decir las cosas por su nombre que mentirte a ti mismo al respecto.
2) He visto equipos estimar historias con puntos y luego estimar tareas en horas como una especie de verificación de su estimación anterior. Hacer esto en realidad puede desencadenar conversaciones sobre lo que implica cumplir una historia que el equipo podría no tener de otra manera, especialmente si han estado haciendo estimaciones de horas durante años. Por ejemplo, un miembro del equipo puede decir "me llevará 2 horas completarlo" y otro dice "¿con o sin el tiempo que le llevará aprovisionar el nuevo servidor en el que se encuentra?" y la primera persona responde "Espera, ¿necesitamos un nuevo servidor para esto?" etcétera. Buena conversación y está agregando valor. Dicho esto, tendría el objetivo de alejarme de esas estimaciones de horas tan pronto como el equipo se sienta cómodo teniendo esas discusiones sin las horas por dos razones:
1) Todavía tienes el mismo problema con las horas que siempre tienes. Los humanos aún son terribles para estimar el tiempo, los gerentes aún intentarán hacer evaluaciones extrañas de estimación a realidad, y todos tendrán una inclinación natural a hacer que el equipo cumpla con sus horas en lugar de entregar valor.
2) Agregar estimaciones como esta ancla las tareas. Crea una aversión a modificar las tareas, eliminarlas o agregar nuevas tareas. En mi experiencia, las tareas deben ser una herramienta para que el equipo organice su trabajo de la manera que más les ayude y no deben ser una vara de medir.
Los puntos de la historia se utilizan como una medida de complejidad relativa y, con el tiempo, establecen la velocidad del equipo: una cantidad promedio de trabajo que un equipo de scrum estable puede realizar durante una iteración fija. La estimación de puntos de la historia de IMO es una práctica fundamental de scrum que ayuda a capacitar al equipo para administrar y asumir sus compromisos de iteración.
Las estimaciones de horas se utilizan para impulsar la discusión sobre las tareas individuales necesarias para completar una historia. ¿Necesitas tareas? Depende de la madurez del equipo. Los equipos inmaduros pueden beneficiarse de las estimaciones de horas cuando no tienen una gran experiencia en el dominio y no pueden hacer una estimación de complejidad relativa con los puntos de la historia. La mayoría de los equipos maduros con los que trabajo dejarán de estimar horas porque lleva mucho tiempo y, a la larga, es más difícil hacer una estimación precisa de horas frente a la estimación de puntos de la historia y la planificación basada en la velocidad.
Nota al margen: con demasiada frecuencia he visto equipos inmaduros que dependen únicamente de estimaciones de horas que se abren a la microgestión por parte de PM tradicionales que piensan que un equipo que tiene X horas de capacidad e Y horas de tareas estimadas completará todo su trabajo en una iteración cuando x = y.
Entonces, ¿haces puntos de historia, horas o ambos? Depende del equipo. Pregunte a los miembros de su equipo si ven valor en alguna de las prácticas de estimación para que comprenda qué funciona, qué no y en qué dirección(es) su equipo puede mejorar.
Los puntos de la historia y las estimaciones basadas en el tiempo se pueden usar de manera complementaria en Scrum.
Los puntos de la historia tratan principalmente de determinar la capacidad del sprint. Así que miras la velocidad de tu equipo y la usas como una predicción aproximada de la capacidad para futuros sprints.
Sin embargo, una vez que haya cargado historias hasta su capacidad de puntos de historia, a veces también es útil hacer una estimación basada en el tiempo. Las razones de esto son:
Por supuesto, hacer estimaciones tanto basadas en el tiempo como en el punto de la historia aumenta el tiempo y el esfuerzo que el equipo dedica a la estimación. Corresponde al equipo decidir si el esfuerzo adicional vale la pena.
Estimas la historia utilizando los puntos de la historia durante la primera parte de la reunión de planificación del sprint; esto te brinda una forma rápida de determinar cuántas historias puede llevar el equipo al sprint en un tiempo bastante rápido.
Muchos equipos hacen eso y ya está. Pero si haces la segunda parte, y divides la historia en tareas, usas horas para las tareas. El trabajo pendiente del sprint se basa en el total de horas de todas las tareas del sprint. El avance puede aumentar y aumenta, ya que la estimación para completar puede aumentar a medida que comprende mejor la tarea.
En resumen, entonces: usa puntos para la historia, y luego horas para las tareas dentro de la historia.
Personalmente, evitaría usar horas ya que es imposible estimar con precisión cuánto tiempo llevará una tarea. Creo que los puntos de la historia son la mejor manera de estimar las historias y no creo que sea necesario estimar las tareas que el equipo debe hacer para completar la historia.
jeff lindsey
charlie