¿Cómo estimar tareas en scrum?

8

Digamos que tenemos una acumulación de historias de usuarios, cada una con un número estimado de puntos de historia, y ahora estamos haciendo la planificación de Sprint.

Ahora, las Historias deben dividirse en tareas y muchos recursos de Scrum sugieren que cada tarea debe estimarse en horas-persona. Como todas las preguntas han sido discutidas por el equipo en este punto, la estimación de una tarea no debería tomar más de un minuto . Sin embargo, dado que una tarea no debe durar más de un día, asumir un sprint de tres semanas con 8 desarrolladores significa 120 tareas, y tomar dos horas solo para estimaciones me parece un poco demasiado.

Sé que los equipos experimentados pueden omitir o reducir las estimaciones de tareas, pero digamos que aún no estamos en esa etapa.

En su experiencia, ¿cuántas tareas hay en un sprint y cuánto tiempo debería tomar estimarlas todas? (Estimar solo la mitad de ellos no tiene mucho sentido, ¿verdad?)

Aclaraciones:

Sé que la respuesta depende de la longitud del sprint y el tamaño del equipo, así que supongamos 8 desarrolladores y tres semanas.

Los números mencionados pueden ser reglas generales, pero incluso si están apagados (por ejemplo, más tareas, menos tiempo necesario para estimar cada una) terminaremos con aproximadamente 2 horas para la estimación. Entonces, tal vez la pregunta debería ser: "¿Qué porcentaje de la reunión de planificación debe reservarse para la estimación de la tarea pura, y no tenemos mejores cosas que hacer?"

scrum planning user-story

— Cefalópodo
fuente

2

Su pregunta se basa en un malentendido de lo que "debería" significar

— Dave Hillier

3

Estás hablando de 120 horas hombre de trabajo por desarrollador. ¿No quieres pasar 2 horas por desarrollador para planificar ese trabajo?

— CodeCaster

3

Muchos de los números (1 minuto para estimar tareas, 1 tarea toma no más de 1 día) son reglas generales. Si es una tarea que nunca ha hecho antes, tomará más tiempo estimarla. Algunas tareas tomarán menos de un día, mientras que otras tomarán más de un día. Las historias más complejas pueden dividirse en más tareas que las historias más simples. No creo que haya una buena respuesta para la cantidad de tareas en un sprint o cuánto tiempo llevará estimarlas.

— Thomas Owens

3

Esto no es un duplicado, esa otra pregunta tiene una dirección completamente diferente. Traté de aclarar la pregunta.

— Cefalópodo

3

Definitivamente no es un duplicado de la pregunta registrada. Esta pregunta es sobre tareas, la otra es sobre historias. Son casi tan similares como las funciones y los programas.

— Bryan Oakley el

9

Francamente, creo que si haces esta pregunta, de hecho no estás completamente convencido del uso de la planificación de sprint.
El punto de la planificación del sprint es llevar al equipo a un estado en el que se sientan cómodos comprometiéndose con un conjunto dado de historias de usuarios, donde sientan que saben lo suficiente como para comenzar. Ya sea que tome una hora, o 2 de 4 o todo el día está completamente fuera de lugar; se hará cuando se haga.
Digamos que quiere acortarlo y limitarlo a 2 horas. El hecho de que necesiten información no cambiará, por lo que inevitablemente terminarás con porciones de lo que solía ser la planificación del sprint, untado sobre el resto de tu sprint.
Al final, todo lo que importa es que el equipo pueda comprometerse con algún trabajo y realmente entregar ese trabajo a satisfacción de ellos mismos y de los demás interesados. Todo lo demás no importa. Concéntrese en lo que realmente ofrece valor, no se centre en las métricas de vanidad.

PD: no importa la cantidad de literatura que indique que debe estimar las tareas en horas, todavía me parece una idea terriblemente inútil y contraproducente, y sé que no estoy solo en esto.

— Stefan Billiet
fuente

Creo que es generalmente (no horriblemente ) inútil para los equipos scrum experimentados, pero es una herramienta valiosa para los nuevos equipos scrum que todavía están aprendiendo cómo estimar historias.

— Bryan Oakley

1

¿Quieres elaborar? Siento que estimar en horas es un desperdicio, porque las personas son malas para estimar en números absolutos y no hay una manera rentable de mejorar. Sin embargo, somos relativamente buenos para estimar cuánto más grande es una historia que otra (números relativos). Así que cuanto antes la gente se deshaga de la tendencia a estimar todo en horas, mejor. También siento que hay mucho énfasis en la estimación y no lo suficiente en la creación de un sistema de flujo basado en extracción (esencialmente haciendo todo lo posible en un intervalo de tiempo y deteniéndose cuando el cliente está satisfecho).

— Stefan Billiet

1

En mi experiencia, somos muy buenos para estimar en horas, cuando el trabajo es bien conocido y pequeño. "Reconstruir el índice de la base de datos" - 1 hora. "Agregar nuevos iconos a la barra de herramientas y menús" - 2 horas. Si las tareas son tan grandes que no se pueden estimar, son demasiado grandes o están mal definidas. El ejercicio de estimar ayuda a los equipos jóvenes a asegurarse de que estén pensando en todo el trabajo: ¿recordamos agregar tareas para las pruebas? ¿Pensamos en agregarlo al instalador? El objetivo no es ser bueno para estimar tareas, sino para estimar puntos de historia. La estimación de tareas es una ayuda para el aprendizaje.

— Bryan Oakley

Punto justo, pero ¿reconstruir el índice DB realmente va a tomar 1 hora? Porque decirlo implica un límite de tiempo absoluto para esa tarea. Crea expectativas y puede conducir a todo tipo de juegos de culpa desagradables cuando termina tomando medio día. Esa es la diferencia entre puntos y horas: "horas" implica absoluta, "puntos" no. Además, ¿con qué frecuencia el trabajo de conocimiento es realmente conocido y pequeño? Me imagino que es más fácil para el equipo usar las horas como ayuda para el aprendizaje, pero corre el riesgo de que se estanquen en una forma de trabajo subóptima.

— Stefan Billiet

Re "... decirlo implica un límite de tiempo absoluto para esa tarea". No lo hace La estimación de la tarea es solo una estimación, no un contrato o promesa. Las estimaciones individuales realmente no significan nada en absoluto. En total, sin embargo, debe quedar claro si los puntos de su historia están en el estadio o no. He visto casos en los que la estimación inicial de dos historias era igual, pero una terminó con más del doble de horas que la otra. El mero acto de tratar de estimar tareas trajo nueva información a la luz. Aprendimos de esto, y nuestra estimación de la historia mejoró.

— Bryan Oakley

1

En su experiencia, ¿cuántas tareas hay en un sprint y cuánto tiempo debería tomar estimarlas todas? (Estimar solo la mitad de ellos no tiene mucho sentido, ¿verdad?)

Esto es como preguntar cuántas gotas de lluvia hay en una tormenta eléctrica. No hay absolutamente ninguna manera de responder a esta pregunta, incluso si habla de dos tormentas diferentes del mismo tamaño. No hay una regla general, sin importar el tamaño del equipo o el tamaño del sprint.

El punto de estimar las horas en las tareas es para que el equipo pueda aprender a estimar mejor sus historias. Por ejemplo, considere dos historias que ha estimado: una se estima que es un 2, y una es un 4 o 5. Cuando comienza a distribuirlo, se da cuenta de que ambos tienen aproximadamente la misma cantidad de horas asignadas a las tareas. ¿Qué te enseña eso?

La única regla general que creo que puedo dar es que, si su equipo tiene una velocidad estable, no necesita estimar las tareas. Si encuentra que su velocidad es inestable, es probable que sus habilidades de estimación sean débiles. Puede fortalecerlos desglosando historias en tareas en el momento de la planificación como un tipo de verificación de cordura para su estimación.

En su pregunta, dice que su equipo aún no está allí, por lo que la estimación es importante. Si eso es cierto, no se preocupe por el tiempo que pasa haciéndolo. Tomará tanto tiempo como sea necesario. Estás haciendo una inversión en tu equipo. Sí, al principio tomará mucho tiempo, pero espero que aprendas de la experiencia. Puede aprender que es una pérdida de tiempo, o puede aprender que no es tan inteligente para estimar como cree.

Recuerde: scrum no es un conjunto de reglas que debe seguir, sino un conjunto de herramientas para ayudarlo a planificar y organizar su trabajo. Cada vez que estas herramientas obstaculicen su productividad, debe dejar de usarlas. Asegúrese de que realmente interfieran con su productividad en lugar de dar la apariencia de hacerlo.

— Bryan Oakley
fuente

1

Asumir un sprint de tres semanas con 8 desarrolladores significa 120 tareas, y tomar dos horas solo para estimaciones me parece un poco demasiado.

Para mí, esto significa que 8 desarrolladores pasan 15 minutos para planificar las próximas 3 semanas. ¿Eso es demasiado? Eso es como un stand up diario.

Es un estimado. Planifica tu primer sprint. Toma buenas notas y medidas. Su primer sprint probablemente estará fuera de lugar. Si esto es un problema, ponga el tiempo y los pasos necesarios para mejorar el siguiente. ¿Las tareas tardan más de lo esperado? ¿Puede cada desarrollador hacer tantas tareas en un sprint dado como esperaban?

Sea abierto y honesto sobre lo que realmente se estaba haciendo y cuánto tiempo llevó. Si las personas tienen miedo, simplemente jugarán con el sistema. Basará sus decisiones de planificación en datos incorrectos. Si demasiadas tareas toman más de un día (o lo que creía que deberían tomar), determine si se dividieron en pedazos lo suficientemente pequeños.

Es posible que sus desarrolladores no tengan un total de 8 horas al día para trabajar en tareas o lo que sea que la gerencia de números mágicos quiera escuchar para sentir que obtienen un día completo de trabajo por un día completo de pago.

¿Sería algo horrible descubrir después de 2 semanas que completó un sprint de 3 semanas o solo completó el 75% de las tareas al final del sprint? Aprenda de lo inesperado (Esto es una estimación, así que no nos detengamos en ellos y los llamemos errores).

El objetivo es hacer feliz al cliente en el contexto de lo que quiere que se haga en el tiempo y los recursos dados. No es para chupar la voluntad de vivir de cada programador que tienes para completar este proyecto.

Entonces, para responder a tu pregunta: solo haz tu mejor esfuerzo para estimar tu primer sprint. Aprende de él y ajusta el siguiente. Repetir.

— JeffO
fuente

1

Mi propia opinión es que la estimación de las horas de trabajo es una pérdida de tiempo en la planificación del sprint. En general, las estimaciones son incorrectas y no obtengo ningún valor al informar sobre ellas. Sin embargo, muchas herramientas ágiles de seguimiento de tareas utilizan estas horas para generar una reducción de carga, por lo que necesitamos algo allí.

Para ahorrar tiempo, comencé a seguir este proceso:

Establezca cada tarea creada en "1 hora" tan pronto como se cree la tarea.
A medida que los desarrolladores abordan las tareas a lo largo del sprint, si piensan que la tarea lleva más de una hora, pueden actualizarla a un valor más realista.
A medida que se completan las tareas, los informes de preparación se actualizan en las horas restantes.

Aún tendrá la capacidad de ver cómo va el progreso y si va por buen camino, pero puede usar su tiempo de planificación de sprint para acciones más valiosas, como comprender las historias y descubrir qué tareas deben realizarse.

— Jay S
fuente

1

TL; DR

¿Cuántas tareas hay en un sprint y cuánto tiempo debería tomar estimarlas todas?

Su pregunta no tiene respuesta canónica posible. Si bien ciertamente puede usar algunas reglas generales para calcular un límite superior razonable para el volumen de la tarea, no hay una relación de conversión universal para historias a tareas o tareas a horas hombre.

Por ejemplo, una regla general comúnmente aceptada es que una tarea debe dimensionarse entre medio día y dos días para que el ciclo de retroalimentación hecho / no hecho permanezca ajustado. Los equipos pueden violar esta regla general, y no lo hacen, ya que no es un requisito marco, pero los equipos más exitosos con los que he trabajado siguen el espíritu de esta regla.

Tareas por Sprint

Sé que la respuesta depende de la longitud del sprint y el tamaño del equipo, así que supongamos 8 desarrolladores y tres semanas.

Esto es axiomáticamente incorrecto, ya que el número de tareas depende del número de historias y la cantidad y granularidad de las tareas descompuestas de cada historia. Sin embargo, puede calcular un límite superior aproximado para la comprobación de la cordura.

Si asume a priori que:

cada tarea requiere solo un desarrollador (este no suele ser el caso)
El 30% de su sprint es consumido por la sobrecarga del marco (este número varía según la longitud del sprint)
no está aplicando ningún factor falso por el hecho de que las horas de trabajo productivas son generalmente <= 6 horas por día de trabajo

entonces tiene 10.5 "días" disponibles para tareas por desarrollador para asignar a tareas en cada sprint. Suponiendo además:

8 desarrolladores
todos los desarrolladores son intercambiables
no hay actividades de cola o dependencias entre tareas
incluye la definición de actividades realizadas como tareas explícitas

luego, seguir la regla de tamaño de tarea recomendada le daría a su equipo una capacidad entre 21-148 tareas por sprint de tres semanas.

Evite estimar tareas en horas hombre

La solución simple aquí es evitar la estimación de tareas en horas de trabajo ideales y arrojar todos los supuestos problemáticos (ya menudo inexactos) por la borda. Simplemente no aceptando historias en el sprint que excedan su velocidad sostenible, resuelve la mayoría de sus problemas de planificación del sprint sin estimar en horas.

Al asegurarse de que sus historias se descompongan en tareas hechas / no hechas del tamaño adecuado de no más de un par de días, puede ver rápidamente si aceptó por error una historia que es más compleja que su estimación de punto de historia, o si fue un trabajo oculto que necesita ser documentado y revisado con el propietario del producto durante la planificación de Sprint.

Los equipos saludables dedican aproximadamente medio día a las tareas de descomposición para el Backlog de Sprint. Si no se toma el tiempo para hacer esto en la segunda mitad de la planificación de Sprint, entonces es mucho más probable que descubra enredos, dependencias inesperadas o trabajo no planificado más adelante en el sprint.

Una reunión de Sprint Backlog de cuatro horas representa menos del 3% de la duración del sprint de tres semanas, y es donde se realiza la mayor parte del diseño y el análisis arquitectónico dentro del marco Scrum. ¿Reducir el riesgo al 2% al reducir el análisis de tareas realmente vale la pena el riesgo para su proyecto? Yo diría que no, pero su kilometraje puede variar.

— CodeGnome
fuente

1

Asumir un sprint de tres semanas con 8 desarrolladores significa 120 tareas, y tomar dos horas solo para estimaciones me parece un poco demasiado.

Su suposición no es correcta porque no todos los miembros del equipo participan en la planificación de cada tarea. De hecho, para las historias, todos los miembros participan en la estimación de todas las historias, pero para las tareas, generalmente un par de miembros del equipo calculan cada tarea.

Entonces, si en su ejemplo, cada dos miembros estiman una tarea, solo toma aproximadamente media hora estimarlos a todos.

— Amir M
fuente