"¿Puedes preparar un informe de sprint?" suele significar que alguien quiere saber, en términos sencillos, si el equipo hizo lo que dijo que iba a hacer. Es una pregunta más acotada de lo que parece: casi todo lo que acaba en un informe de sprint es un gráfico de burndown que nadie lee con detenimiento o una lista de viñetas escrita de memoria la mañana de la revisión. Ninguna de las dos cosas responde de verdad a "¿entregamos lo que nos comprometimos a entregar?", que es la pregunta que merece la pena responder.
Lo que un informe de sprint realmente necesita
Reducido a lo esencial, un informe de sprint necesita cinco cosas: a qué se comprometió el equipo al inicio del sprint (no con lo que terminó, que son cifras distintas en cuanto el alcance se mueve); qué se entregó realmente; qué se arrastró y por qué; cuánto cambió el alcance después del primer día; y alguna idea de cuánto tardó realmente el trabajo entregado, no solo cuánto hubo. Un informe que se salta la referencia del primer día y solo muestra el contenido final del sprint no puede distinguir un fallo de entrega de un aumento de alcance: ambos se ven idénticos desde fuera a menos que se haya conservado la instantánea del primer día.
Resumen del sprint: un equipo, un sprint
Esa es la forma que adopta la vista Resumen del sprint de Agile Gauge. Elige un sprint, el actual, si tiene actividad real, o busca hacia atrás entre los últimos seis sprints finalizados hasta encontrar uno que la tenga, y muestra Fiabilidad del compromiso, Entregado, Arrastre, En curso, Cambio de alcance, y el tiempo de ciclo tanto de la mediana como del percentil 85 para los elementos finalizados de ese sprint, cada uno como una tarjeta de estadística en la que se puede hacer clic.
De dónde sale realmente "comprometido"
La fiabilidad del compromiso solo significa algo si "comprometido" se mide con honestidad. Resumen del sprint lo define como lo que contenía el sprint al final de su primer día: leído del propio historial de Azure DevOps cuando está disponible, y reconstruido reproduciendo el historial de asignación al sprint de cada elemento cuando no lo está (algo habitual en datos importados de otro sitio). La página indica claramente qué método usó. Si ninguno de los dos métodos puede establecer una instantánea real del primer día, la fiabilidad del compromiso y el arrastre no se muestran en absoluto, en lugar de recurrir en silencio al contenido actual del sprint: un número construido a partir de "lo que hay en el sprint ahora mismo" saldría cercano al 100% sin importar lo que realmente ocurriera, lo cual es peor que no tener número.
Los elementos entregados y comprometidos divididos entre los elementos comprometidos dan la fiabilidad del compromiso como porcentaje; los elementos eliminados por completo de Azure DevOps se excluyen de ambos lados, ya que no se debería acreditar ni penalizar a un equipo por trabajo que el negocio retiró. Un elemento sigue contando como entregado si se cerró hasta 24 horas después del final del propio sprint, ya que la mayoría de los equipos cierran el último elemento o dos la mañana después de la revisión. El cambio de alcance es (elementos añadidos después del primer día más elementos eliminados después del primer día) dividido entre el total de elementos; un elemento que se añade y más tarde se vuelve a eliminar no cuenta en ninguna de las dos categorías.
Respaldar cada número con los elementos reales
Un número de informe de sprint que no se puede cuestionar en la sala no merece la pena mostrarlo. Cada tarjeta de estadística de Resumen del sprint abre exactamente los elementos que hay detrás de ella, Comprometido, Entregado, Arrastre, En curso, y los grupos Añadidos y Eliminados de Cambio de alcance por separado, y cada elemento de esas listas se abre además a su propio tiempo de ciclo, su recorrido por las etapas de flujo de trabajo mapeadas de tu equipo, y un enlace directo a Azure DevOps. "El arrastre fue alto este sprint" se convierte en una lista real de qué elementos se arrastraron y por qué, en lugar de un número que alguien tiene que creerse sin más.
Cuando el informe es para una reunión, no solo para una pantalla
Resumen del sprint está pensado para leerse en pantalla, cambiando de sprint uno a uno desde un selector. Cuando el informe tiene que presentarse ante una sala, una revisión de sprint, una retrospectiva, la vista Resumen de retrospectiva de Agile Gauge cubre un terreno similar con seis KPI calificados frente a objetivos que fija tu equipo, más un diseño de impresión ajustado para caber en un puñado de páginas en lugar de una presentación de diapositivas hecha a mano. Las dos vistas comparten los mismos cálculos subyacentes, así que una cifra no cambia según desde qué pantalla se abra.
Lo que esto no cubre
El primer sprint de un equipo, o un equipo sin ningún historial de sprints, muestra "aún no hay sprints" en lugar de cifras inventadas. Un sprint muy grande reconstruido a partir del historial de elementos, en lugar de leído directamente de Azure DevOps, puede ocasionalmente no recuperar un puñado de movimientos, lo que puede hacer que la fiabilidad se lea algo más generosa de lo que debería; la página te indica cuándo usó el método reconstruido, de modo que esa salvedad permanece visible en lugar de oculta. Y cada cifra de la página está prefiltrada según los tipos de elemento de trabajo que tu organización haya configurado para contar en las métricas; hasta que eso se configure, se incluyen todos los tipos.
Cómo llegar
Resumen del sprint necesita una cosa configurada de antemano: el mapeo de etapas de flujo de trabajo de tu equipo en Configuración, para que Agile Gauge sepa cuáles de tus estados cuentan como iniciados y cuáles como terminados. Una vez configurado eso, Resumen del sprint lee el historial de tu Azure DevOps y construye el informe en el momento en que abres la pantalla: nada que exportar, nada que escribir dos veces y nada que se desactualice entre una revisión de sprint y la siguiente.
Agile Gauge empieza en $20 al mes para hasta 2 usuarios. Empieza una prueba gratuita de 14 días: todas las funciones, sin tarjeta.