Burn Down Chart: ¿Cuál es la definición de trabajo realizado en Scrum?

¿Cuál es la definición de trabajo realizado en Scrum?

Trabajo que cumple con la Definición de Hecho, que es definida por el Equipo.

El problema con esto es que el trabajo que se cierra a diario no se muestra en el gráfico Burndown

Este es el comportamiento correcto. Desde la perspectiva de Scrum, una historia incompleta proporciona valor cero, por lo que el trabajo pendiente muestra un progreso cero.

da la impresión de que no lograremos el objetivo del sprint.

Eso no es para lo que es el burndown. El avance es principalmente una herramienta para rastrear la velocidad, que solo es útil para futuros Sprints. Además, incluso si su trabajo pendiente rastreara un esfuerzo inútil, aún no sería una herramienta adecuada para determinar su probabilidad de alcanzar su Sprint Goal. A menos que su Sprint Goal sea 'completar todas las historias del Sprint', que es un objetivo bastante pobre.

¿Alguien puede dar una idea de cómo se define el trabajo?

Depende para qué esté usando ese trabajo rastreado. Burndown, específicamente, se usa para rastrear la velocidad, lo que significa que solo se ocupa del trabajo que cumple con la Definición de Listo.

El trabajo está hecho o no está hecho

Scrum no requiere el uso de historias de usuarios, puntos de historia o gráficos de quemado. Suelen usarse como práctica recomendada, pero es importante comprender que no son requisitos del marco.

Dicho esto, los marcos ágiles ampliamente aceptados generalmente tratan el trabajo como hecho o no hecho . Los elementos del Product Backlog y Sprint Backlog nunca se "terminan parcialmente", por lo que no se queman hasta que cumplen la Definición de Terminado.

Tamaño correcto de su granularidad

Si desea una visibilidad más profunda de lo hecho/no hecho, probablemente necesite refactorizar su Sprint Backlog y el gráfico de trabajo pendiente para realizar un seguimiento de las tareas en lugar de las historias de los usuarios. Si hace eso, puede quemar cada tarea como si estuviera 100% completa, lo que le brinda una línea de tendencia más matizada.

Sin embargo, tenga en cuenta que "más matizado" no significa mejor o más preciso. La sobrecarga adicional de descomponer y rastrear el trabajo a niveles significativamente más granulares (idealmente teniendo en cuenta los criterios de INVEST ) a menudo supera el beneficio de hacerlo. La granularidad excesiva rara vez conduce a una mejor entrega de las historias de usuario o de los Sprint Goals. En otras palabras, generalmente crea la ilusión de una mayor precisión sin hacer que los procesos de estimación o entrega sean más efectivos.

Además, el seguimiento excesivo de tareas a menudo anula los principios de autoorganización de los marcos ágiles, lo que lleva a una planificación más inicial y un diseño menos emergente. Si restringe demasiado el espacio de la solución a través del diseño y la planificación prescriptivos por adelantado, elimina la colaboración y la flexibilidad justo a tiempo/suficiente que hace que los marcos de control empíricos como Scrum sean ágiles en primer lugar.

Líneas de tendencia: una función del tamaño del artículo pendiente

Tener una línea de tendencia que no se mueve hasta el final de un Sprint puede ser un olor a implementación del marco, pero las líneas de tendencia irregulares o escalonadas suelen ser solo un síntoma del seguimiento de grandes cantidades de trabajo. Lo que quieres es una cadencia predecible, no necesariamente un gráfico fluido. Siempre que tenga una tendencia a la baja cada dos días y cumpla con su Sprint Goal la mayoría de las veces, no me preocuparía. ¡Solo es un problema si crea un problema!

Por otro lado, si el equipo Scrum realmente necesita visibilidad adicional, entonces todo el equipo debe aceptar la sobrecarga adicional de planificación y seguimiento a un nivel más granular. Solo el Equipo Scrum puede determinar si se trata de una compensación útil o no.

La pregunta que debes hacerte es:

¿Qué información queremos obtener de un burndown?

Diferentes equipos utilizarán el avance de diferentes maneras.

Un enfoque popular consiste en quemar las historias completas. Esto le da una indicación al equipo si están 'retrocediendo' el sprint, es decir, que las historias solo se terminan hacia el final del sprint en lugar de hacerlo de manera constante a lo largo de la duración del sprint. Esto puede indicar problemas como que las historias son demasiado grandes o que las pruebas tienden a cambiar hacia el final del sprint.

A otros equipos les gusta quemar el esfuerzo y, por lo tanto, pueden usar tareas (o subtareas usando la terminología de JIRA). Esto le permite al equipo realizar un seguimiento del esfuerzo que había estimado para completar las tareas en comparación con el esfuerzo real que están realizando. Puede dar una advertencia temprana de que es posible que el equipo no complete todo el trabajo que esperaba hacer en el sprint.

He estado usando TFS durante 4 meses, así que todavía no soy un experto. Pero creo que el trabajo pendiente proporcionado por TFS (según tengo entendido) no funciona bien. Primero debe almacenar la disponibilidad de todos los miembros del equipo y la cantidad de tiempo que estarán disponibles para el sprint. Luego, también debe registrar la cantidad de tiempo restante por tarea.

A mí esto me parece mucho trabajo que no es necesario. Acabo de crear un gráfico basado en una consulta y creé mi propio trabajo pendiente en el nivel de tarea. Esto le muestra al equipo suficiente información sobre las tareas que están en 'pendiente', 'en progreso' y 'terminadas'.