Eso es 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 se hacen o no se hacen; al tratar de rastrear las desviaciones de las estimaciones de planificación basadas en el tiempo en su reducción, en realidad está reestimando su programa en lugar de estimar el producto de trabajo restante.

En Scrum, debes medir el progreso hacia un objetivo Sprint en lugar de medir el cuadro de tiempo de Sprint. Esto mantiene el enfoque en la capacidad del equipo y la entrega de funciones en lugar de en los ajustes de programación continua.

Tareas vs. Historias

Estás confundiendo tareas e historias. Las historias comprenden todas las tareas necesarias 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, puede decirse que la revisión del código está completa o no, independientemente de las otras tareas.

Burn-Down

En Scrum, tu tabla de quema muestra la cantidad de trabajo restante para el sprint o proyecto. Las tablas de quemado reales a menudo tienen mesetas; En algunos casos, la gráfica puede incluso subir. Por ejemplo, en un sprint de una semana con dos historias que valen 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 cumple con la definición de hecho. Si estás utilizando las horas ideales en lugar de los puntos de la historia, lo único que cambia es tu escala.

Time-Boxing

La práctica generalmente aceptada es asegurarse de que sus tareas se descomponen 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 desde el punto de vista diario o el Registro de Sprint; 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 las mesetas son normales, pero si nadie está aumentando los bloqueadores en las paradas diarias, pero parece que su quema está estancada, eso es generalmente una señal de que el Sprint Backlog se ha estimado mal o hay "trabajo invisible" que debe hacerse explícito en su proceso.

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

Yo diría que debe agregar los tres elementos en una sola tarea y las tres personas deben trabajar juntas en ello.

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

No importa. Siempre y cuando sea relativamente consistente en las historias, su gráfico de quemado seguirá funcionando de cualquier manera. Utilice la forma más natural para que su equipo informe.

Mi equipo en realidad hace una especie de híbrido, aunque no por acuerdo formal. Dedicamos 16 horas si pensamos que una tarea llevará dos días a una persona, pero si dos personas terminan trabajando juntas en ella, no la cambiamos.

Después de la estimación inicial, informalmente se convierte en más de un porcentaje completado para nuestro equipo que las horas restantes. Si originalmente pensamos que tomaría dos días, pero después de un día, creemos que solo se ha completado 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 para los 3 días restantes.

Al principio, eso me molestó como un scrum master, pero por extraño que parezca, es una forma muy natural de dar estimaciones, porque los desarrolladores realmente odian agregar horas a una estimación. Todo promedia para que la quema siga siendo ú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), haga que las personas completen el tiempo restante en las tareas y luego divida las tareas por persona.

Dicho esto:

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

Divida la tarea en múltiples tareas e ingréselas como tareas donde cada persona sea manejada por una persona diferente.

Tarea original: corregir algo

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

• Dev A - Solucionar el problema
• Dev B - Ayudar a Dev A a solucionar el problema (es decir, programación de pares, revisión de código)
• Dev A - dev prueba la solución usando el conjunto de datos X
• Dev B - dev prueba la corrección usando el Conjunto de datos Y