En mi empresa, una sola tarea nunca puede ser completada por un individuo. Habrá una persona separada para el control de calidad y la revisión de código en cada tarea. Lo que esto significa es que cada individuo dará sus estimaciones, por tarea, en cuanto a cuánto tiempo llevará completar.

El problema es, ¿cómo debo acercarme a quemar? Si agrego las horas juntas, suponga la siguiente estimación:

10 horas - Tiempo de desarrollo

4 horas - QA

4 horas - Revisión del código.

Estimación de tarea = 18 horas

Al final de cada día, pido que la tarea se actualice con "cuánto tiempo queda hasta que esté terminada". Sin embargo, cada persona generalmente solo piensa en su parte. ¿Deberían marcar el esfuerzo restante y luego AGREGAR las estimaciones de esfuerzo a eso? ¿Cómo están haciendo esto?

ACTUALIZAR

Para ayudar a aclarar algunas cosas, en mi organización cada tarea dentro de una historia requiere 3 personas.

1. Alguien para desarrollar la tarea. (hacer pruebas unitarias, ect ...)
2. Un especialista en control de calidad para revisar la tarea (principalmente realizan pruebas de integración y regresión)
3. Un líder técnico para hacer la revisión del código.

No creo que haya un camino equivocado o un camino correcto, pero este es nuestro camino ... y eso no va a cambiar. Trabajamos en equipo para completar incluso el nivel más pequeño de una historia siempre que sea posible. En realidad, no puede probar si algo funciona hasta que se complete el desarrollo, y tampoco puede revisar la calidad del código ... así que lo mejor que puede hacer es dividir las cosas en pequeños segmentos lógicos para que se pueda probar la funcionalidad mínima. revisado lo antes posible en el proceso.

Mi pregunta para aquellos que trabajan de esta manera sería cómo grabar una "tarea" cuando se configuran de esta manera. A menos que una Tarea tenga sus propias subtareas (que JIRA no permite) ... No estoy seguro de la mejor manera de realizar un seguimiento diario de "lo que queda".

Eso son 3 tareas, no una.

Puede ser una característica / historia, pero son tres tareas. Una sola persona puede completar una tarea en un tiempo finito.

TL; DR

Está utilizando el quemado incorrectamente de varias maneras. Las tareas y las historias están hechas o no hechas; Al tratar de rastrear las desviaciones de las estimaciones de planificación basadas en el tiempo en su consumo, en realidad está volviendo a estimar su horario en lugar de estimar el producto restante del trabajo.

En Scrum, deberías medir el progreso hacia una Meta de Sprint en lugar de medir la casilla de tiempo del Sprint. Esto mantiene el enfoque en la capacidad del equipo y la entrega de características en lugar de en los ajustes continuos de programación.

Tareas vs. Historias

Estás combinando tareas e historias. Las historias comprenden todas las tareas requeridas para completar la historia según la "definición de hecho" de su equipo. La historia se considera 100% incompleta a menos que todas sus tareas estén completas. En Scrum, las historias siempre se estiman de alguna manera; con mayor frecuencia, se estiman en puntos de historia.

Las tareas son los pasos o hitos necesarios para completar la historia. Si bien cada tarea puede tener dependencias y requisitos previos, ciertamente puede decir que la revisión del código está completa o no, independientemente de las otras tareas.

Quemar

En Scrum, su gráfico de quemado muestra la cantidad de trabajo restante para el sprint o proyecto. Los gráficos reales de quemados a menudo tienen mesetas; en algunos casos, el gráfico puede incluso aumentar. Por ejemplo, en un sprint de una semana con dos historias por valor de 3 y 5 puntos, sus puntos de datos pueden verse así:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

En este escenario idealista, comienzas con 8 puntos de historia. La historia de 3 puntos se completó el martes por la tarde, mientras que la historia de 5 puntos no se completó hasta el viernes. Los puntos de la historia no se deducen de la quema hasta que la historia cumpla con la definición de hecho. Si está utilizando las horas ideales en lugar de los puntos de la historia, lo único que cambia es su escala.

Time-Boxing

La práctica generalmente aceptada es garantizar que sus tareas se descompongan en trozos pequeños entre 1/2 día y 2 días. La variación de más de un día debe ser evidente a partir de los stand-ups diarios o el Sprint Backlog; no debería haber necesidad de realizar una extracción de estado formal.

También puede realizar un análisis estadístico en el gráfico de quemado para determinar si su sprint tiene una tendencia correcta. Las pequeñas desviaciones o mesetas son normales, pero si nadie está levantando bloqueadores en las paradas diarias, pero su quema parece estancada, eso generalmente es una señal de que el Backlog de Sprint ha sido mal estimado o hay un "trabajo invisible" que necesita ser explícito en su proceso.

¿Puedes definir la tarea de desarrollo como "terminada" antes de que QA haga su parte? ¿Puedes definir la revisión del código como "hecho" antes de que se complete el desarrollo? ¿Se puede "realizar" el control de calidad si la revisión de código y desarrollo no lo está?

Diría que debe agregar los tres elementos en una sola tarea y que las tres personas deben trabajar juntas en ella.

Scrum NO dice que ningún artículo sea responsabilidad de un miembro del equipo. Todo lo contrario: los elementos de registro de sprint son responsabilidad del EQUIPO. Si se necesitan tres personas para realizar una tarea, entonces eso es lo que se necesita.

No importa. Siempre y cuando sea relativamente consistente en todas las historias, su tabla de rendimiento seguirá funcionando de cualquier manera. Use la forma que sea más natural para que su equipo informe.

Mi equipo realmente hace una especie de híbrido, aunque no por acuerdo formal. Dedicamos 16 horas si creemos que una tarea tomará una persona dos días, pero si dos personas terminan trabajando juntas, no la cambiamos.

Después de la estimación inicial, informalmente se vuelve más de un porcentaje completo para nuestro equipo que las horas restantes. Si originalmente pensábamos que tomaría dos días, pero después de un día, creemos que solo está completo en un 25%, tomamos 4 de las 16 horas originales libres. Eso deja 12 horas donde técnicamente estamos estimando 24, porque probablemente deduciremos 4 horas por los 3 días restantes.

Al principio, eso me molestó como scrum master, pero por extraño que parezca, es una forma muy natural de hacer estimaciones, porque los desarrolladores realmente odian agregar horas a una estimación. Todo hace un promedio para hacer que la quema aún sea útil, y eso es lo importante.

El tiempo restante de la tarea no importa mucho: no se puede entregar nada hasta que se complete toda la historia.

Si desea realizar un seguimiento de cuánto tiempo queda en una historia (en general) haciendo que la gente complete el tiempo restante en las tareas, luego divida las tareas por persona.

Eso dijo:

• Las grandes tareas pueden ser una indicación de que sus historias son demasiado grandes. En este caso, la mejor solución es reducir el alcance y el tamaño de las historias, y si lo reduce lo suficiente, el seguimiento del tiempo restante en las tareas ya no importa (ya sea que estén hechas o no, suma de la estimación de las tareas no hechas es lo suficientemente granular).
• SCRUM anima a todos a recoger lo que hay que hacer. Si está asignando tareas a personas (en lugar de roles), entonces potencialmente se está impidiendo entregar una historia, incluso si el desarrollador no está haciendo nada, porque el control de calidad tiene un cuello de botella.

Divida la tarea en varias tareas e ingréselas como tareas donde cada una es manejada por una persona diferente.

Tarea original: arreglar algo

Nuevas tareas: (hijo del padre de la tarea original)

• Dev A - Solucionando el problema
• Dev B - Ayudando a Dev A a solucionar el problema (es decir, programación de pares, revisión de código)
• Dev A: desarrollador que prueba la solución con Dataset X
• Dev B - dev probando la solución usando el conjunto de datos Y