¿Qué puedo decir constructivamente cuando miro el Sprint Burndown?

TL;DR

En primer lugar, nunca "camine por el tablero" ni se acurruque alrededor de un gráfico para su stand-up diario. La reunión es para la coordinación de dependencias, no para informes o análisis de tendencias. ¡Mirar fijamente un incendio no ayuda al equipo a coordinarse!

En segundo lugar, el objetivo de un Sprint es cumplir el Sprint Goal . Si habitualmente alcanza sus objetivos de Sprint con un trabajo pendiente entrecortado, o incluso si cumple sus objetivos sin completar el trabajo pendiente, ¡sus Sprints seguirán siendo exitosos! Las líneas de tendencia menos que ideales presentan oportunidades para la mejora del proceso, ¡pero tener una línea de tendencia ideal para su quemado no es el objetivo de Scrum!

Optimizar para flujo

Está utilizando la herramienta incorrecta para el trabajo. Si bien los gráficos de quemado pueden ser útiles para proyectar tendencias para Sprints más largos o brindar transparencia a las partes interesadas, parece que está abusando de la métrica como una forma de responsabilizar al equipo de algún pronóstico original.

El stand-up diario no está realmente diseñado como una ceremonia para reunirse alrededor de un gráfico de quemado. Realmente es una reunión de coordinación de dependencias, y una mini-reunión del equipo para planificar el trabajo del día.

En lugar de centrarse en el gráfico de trabajo pendiente como su métrica principal, intente centrarse en la coordinación del equipo, lo que a menudo suaviza la línea de tendencia de trabajo pendiente como un subproducto de un flujo mejorado. La guía general es que un Elemento del Backlog de Sprint debe ser de 1/2 a 2 días de esfuerzo. ¿El equipo completó el trabajo que esperaban completar ayer? ¿El trabajo planificado para hoy está bloqueado por dependencias que no se completaron ayer? ¿Hay trabajo recién descubierto que debe planificarse o trabajo no planificado que está consumiendo la capacidad del equipo? Deje que el equipo mencione esas cosas durante la reunión diaria e intente que todos salgan de la reunión con un plan para abordarlas durante la jornada laboral que se avecina.

Cuándo abordar las líneas de tendencia

Como regla general, un gráfico de trabajo pendiente no suele ser útil para el equipo de desarrollo dentro de un Sprint. Sin embargo, a menudo es una gran métrica final para identificar problemas con el tamaño de la historia, la gestión de dependencias y el flujo. Desde la perspectiva del Equipo de Desarrollo, el mejor momento para hablar sobre las pérdidas es probablemente la Retrospectiva de Sprint.

El trabajo viene en todos los tamaños. Sin embargo, dado que el trabajo se realiza o no se realiza , una quema que se estanca hasta el final de un Sprint suele ser un indicador de elementos de trabajo que son demasiado grandes (por ejemplo, más de 4 a 16 horas de reloj de pared cada uno) o un pobre (o incluso ausente) proceso de integración continua . También puede indicar bloqueos ocultos o problemas de proceso que no se plantean en las reuniones diarias ni se reflejan en los acuerdos de trabajo del equipo.

Si históricamente ha tenido un quemado más suave, entonces el gráfico puede ser una señal de advertencia útil de problemas ocultos. Sin embargo, si su quemado siempre ha tardado en converger, entonces es útil cuando el equipo aborda sus procesos de planificación/estimación o gestión de dependencias durante la Retrospectiva de Sprint.

Todos los gráficos de este tipo están, en mi opinión, diseñados para ayudarlo a planificar y priorizar. Estos no son el tipo de actividades que creo que deberían ocurrir durante una reunión diaria normal; se trata de actividades de gestión, no de control. Habiendo dicho eso, trabajo con un gráfico que no es precisamente un gráfico de trabajo pendiente, pero es análogo. Mi carta tiene

• la línea de quemado actual,
• una línea de referencia para el peor de los casos, y;
• serie de umbrales de escalamiento.

Si la curva de trabajo pendiente se acerca al umbral, el equipo puede tomar medidas enjambre o extensión, y yo puedo tomar medidas para preparar los planes propuestos para cuando la curva cruce el umbral.

El primer umbral es en realidad solo un umbral de "información": si la curva cruza el umbral, informo a un conjunto (definido) de partes interesadas que tenemos un problema y que estamos preparando cursos de acción alternativos. De esa manera, nadie se sorprende si necesitamos replanificar, y las partes interesadas tienen la oportunidad de ayudar.

Si la curva cruza el umbral de escalamiento, las partes interesadas y yo tenemos que volver a planificar. En mis proyectos, eso generalmente implica aplazar parte del trabajo a un futuro "análogo de sprint": reajustamos el alcance del trabajo restante para que la curva de quemado vuelva a estar dentro del umbral de control.

Como dije, trabajo en "scrumbut", por lo que no tengo algunas de las limitaciones de scrum. Dicho esto, afirmo que scrum es un método para controlar el trabajo. Si la curva de trabajo pendiente cruza un umbral, entonces el Sprint está fuera de control y necesita una gestión de excepciones. Si, por ejemplo, el trabajo requerido para completar a tiempo supera significativamente la velocidad histórica máxima del equipo, entonces creo que el problema no se puede resolver con scrum. (Como dije, no soy un miembro de scrum, por lo que podría estar equivocado y estaré feliz de corregirlo). Pero el objetivo del gráfico de trabajo pendiente es evitar esa situación. El objetivo debe ser tomar medidas cuando el trabajo supere un umbral inferior, ¿quizás la velocidad promedio?

No tienes que decir cosas constructivas sobre el burndown; es solo una muestra de hechos y no hieres sus sentimientos diciendo que no se ve tan bien hoy.

En su lugar, debe preguntarle al equipo "¿cómo vamos a solucionar esto?".

Básicamente, eso significa que si las personas están de acuerdo en que el trabajo pendiente está fallando, es hora de sentarse con todos y hablar sobre lo que aún se puede hacer en este sprint, lo que no es tan importante y se puede eliminar, si hay una forma más eficiente de completarlo. las tareas que faltan por hacer, etc.

Además, hable sobre la razón por la cual las cosas no van tan rápido como se esperaba. Si bien un "cómo salió mal esto" en profundidad es más una cosa retrospectiva, un rápido "lo que salió mal nos causará más problemas durante el resto del sprint" es importante, de lo contrario, tendrá la misma discusión el la mañana siguiente.

Recuerda también mantener la vista en la meta. Si bien es común seleccionar una cantidad de trabajo que parece factible al comienzo del sprint, también elige un objetivo de "qué queremos lograr", y está bien eliminar algunos elementos o cambiar algunos planes para alcanzar el objetivo en una manera diferente

No creo que debamos mirar de brazos cruzados cómo un equipo se queda atrás. Quiero tomar la información de progreso que tenemos y usarla para rescatar el sprint mientras todavía hay una oportunidad de hacerlo.

El gráfico de quemado es principalmente una medida de qué tan bien estimó el equipo.

No se están quedando atrás.

Probablemente no haya nada que puedas hacer para 'rescatar' el sprint.

(Suponiendo que sea una buena línea constante y que no vaya a curvarse hacia el final del sprint) Lo que puede hacer es manejar las expectativas de las partes interesadas y decirles que llegará tarde antes de que se sorprendan al llegar tarde.