Cómo medir el avance de un proyecto Scrum

Relaciono gráficamente la diferencia entre:

• burn down chart = el objetivo es terminar los puntos y llegar a tener 0 puntos “pendientes” de historias de usuario en los días de sprint
• burn up chart = el objetivo es cumplir los puntos en su totalidad acumulándolos a lo largo de en los días de sprint

Burn-Down chart: Un gráfico de trabajo pendiente a lo largo del tiempo, muestra la velocidad a la que se estan completando los objetivos. Permite extrapolar si el equipo podrá completarel trabajo en el tiempo estimado. Usualmente el trabajo remanente (backlog) se muestra en el eje vertical y el tiempo en el eje horizontal. Muy util para realizar adaptaciones entre los sprints.

Burn-up chart: Muestra el trabajo aportado por el equipo a un proyecto agíl. Util para gestionar el trabajo porque permite tomar decisiones realistas acerca del trabajo pendiente y las expectativas del mismo. Ayuda a encontrar el ritmo sostenible del equipo. Además cuando la velocidad de éste se estabiliza (normalmenteal cabo de 4-5 sprints), podemos hacer un cálculo de cúando podría acabarse el proyecto.

Diagrama de flujo acumulado: Proporciona una visualizacion concisa de las metricas de flujo. Muestra que tan estable es tu flujo y te ayuda a entender dónde concentrarse para hacer que tu proceso sea más predecible.

El burn-down chart muestra el trabajo pendiente
El burn-up chart muestra el trabajo completado

¿Cómo ir midiendo el avance del proyecto?

Lo medimos para que el equipo pueda ir analizando el progreso hecho y revisar si aún se puede cumplir el objetivo planeado al inicio de la iteración. -> Con base a los puntos de la historia.

• Toman en cuenta el sistema de puntos de las historias.
• Enfocadas en el sprint -> 10 días -> Introducir wl numero planeado de puntos para hacer en el sprint
• Se proyecta una gráfica de (estimado) cómo se deben ir concretando los puntos a lo largo de los días.
• El real muestra los que se quemó en ese día.
• Marca también otra línea gris de la tendencia
• Se llena los otros días. Y la linea de tendencia se sigue proyectando.

Burn up chart:
Se plantea un techo a que se debe llegar.

• Se lleva el seguimiento del día.
• Si la gráfica de tendencia está abajo, implica que no vamos a llegar al objetivo.

La gráfica del flujo acumulado.

• Con gráficas de los sprints anteriores (no del día a día del sprint)

• Puedes ver que esta tabla está basada en todos los sprints anteriores.

• Siempre usando los puntos de la historia de usuario.

• Es una gráfica acumulativa. Acumulando los trabajos de todos los sprints anteriores. Deben estar los estados agrupados.

• La línea verde se va aumentando. Es decir que los puntos aumentan.

• ¿Cuánto se tarda una historia de pasar?

• Las historias que se empiezan en un sprint deberían terminarse en ese mismo sprint.

• Se mide tomando la distancia entre la línea de progreso (amarilla) respecto a la verde, tomando como referencia la linea horizontal.

• para analizar los cuellos de botella, podemos ver las distancias verticales. Que nos indican en donde estámos dejando más puntos entre esa fase y el Done.

QA (Quality Assurance, aseguramiento de calidad)
es el proceso posterior a in process
se podría decir que testear y verificar que cumple con el objetivo, etc.
y no, no significa Questions & Answers >: l

Tengo un problema con la pregunta del examen que dice: “Que gráficas me ayudara a medir la cantidad de trabajo que puede completar mi equipo en un sprint” en base a lo que habla el profesor en este video, seria la gráfica de flujo acumulado, o bueno esa es mi deducción y aun así me marca errada la respuesta. Estoy equivocado?

Uno de los valores de Scrum es el de la franqueza, que consiste en tener una colaboración y comunicación continua con el cliente de modo que en todo momento conozca la situación actual del equipo y del proyecto. De esta forma es más sencillo adoptar medidas paliativas y llegar a acuerdos necesarios para mantener la situación bajo control a lo largo de toda la colaboración entre cliente y equipo.

Una de las herramientas que nos brinda Agile y Scrum para potenciar este valor son los information radiators (radiadores de información). Podemos definir los information radiators como una serie de información colocada estratégicamente en un lugar de paso para que cualquiera que pase cerca del equipo pueda ver en un vistazo la situación de su trabajo sin preguntar al equipo directamente. El objetivo es aumentar la comunicación sin necesidad de aumentar el trabajo del equipo ni las interrupciones. Un information radiator debería ser lo suficientemente grande como para que la gente al pasar pueda verlo, se entienda a la primera en un vistazo y esté siempre lo más actualizado posible.

DIAGRAMA

ANTIPATRONES ANTE LOS QUE ESTAR ALERTA

• El equipo termina antes de tiempo todos los sprints porque no están asumiendo trabajo suficiente.
• El equipo no cumple las previsiones sprint tras sprint porque está asumiendo demasiado trabajo.
• La línea de evolución marca caídas pronunciadas en lugar de una evolución más gradual debido a que el trabajo no se ha dividido granularmente.
• El propietario del producto añade o cambia el alcance en mitad del sprint.

“Solo lo que se mide es mejorable” dijo un ponente en alguna conferencia en un tiempo anterior. Las gráficas solucionan

Gráficas:

Burn down chart= trabajo completado
Burn-up chart= trabajo que hemos ido completando

¿Por qué estimar?

.
Puedes leer el artículo completo aquí.
.
¿Por qué estimar en absoluto? ¿Por qué no centrarse simplemente en completar un elemento en un Sprint Backlog a la vez, llevarlo a la calidad de lanzamiento y así medir el progreso en términos de la tasa de valor entregado honesta y genuinamente? Si necesitamos una gráfica para mostrarnos el progreso hacia una meta, ¿por qué no rastrear ese progreso en términos de datos reales en lugar de estimaciones? Además, ¿no permitiría esto que el control empírico del proceso hacia ese mismo objetivo se incorpore al Sprint mismo?

.

El argumento es sólido y el caso de “no estimaciones” en la entrega ágil tiene mucho que decir a favor. Ciertamente, debemos entender y aceptar que medir el progreso sobre la base de los puntos de la historia no es empírico, incluso dentro de los estrechos límites de un Sprint.

.

La entrega de características de trabajo, temprana y frecuentemente, es la única medida de progreso que puede ser verdaderamente satisfactoria a cualquier escala. Sin embargo, lo que razonablemente puede hacer una gráfica de puntos de la historia es darle transparencia al equipo sobre un evento complejo.
.

• Verás, eso es realmente un Sprint. No es solo un flujo de trabajo en el que piezas de valor independientes y discretas están expuestas a un flujo y una atracción uniformes. Su propósito conjunto es alcanzar una meta de Sprint.

.

Ese objetivo puede mitigar un riesgo muy significativo que, en última instancia, hace que un Sprint Backlog sea más que la suma de sus partes. El lanzamiento incremental ciertamente no tiene que posponerse hasta el final de un Sprint y, de hecho, puede ocurrir sobre la base de la entrada en producción y el flujo continuo.

.

Sin embargo, es posible que solo tenga sentido realizar un lanzamiento al final de un Sprint cuando haya un entregable complejo a la mano y haya varias incógnitas con las que hacer malabares. Scrum no hace prescripciones sobre ninguno de estos escenarios o sobre las métricas que debería utilizar un equipo de confianza y autoorganizado.

.

La gráfica de un punto de la historia es una construcción provisional a través de la cual se puede falsificar el control del proceso empírico. Cuando ocurre la liberación, la falsificación termina y el progreso se recalibra. Siempre que comprendamos y aceptemos esto, es posible que no haya ningún problema.

Creo que no es muy claro cómo establecer cuántos puntos se trabajan o logran si no se tiene la experiencia.

Les dejo mi mapa 😄

La grafica de flujo acumulado es la que me permite conocer la cantidad de trabajo que puede completar mi equipo???

Medición del avance del proyecto

Medir el avance del proyecto es importante para que el equipo pueda analizar en base al trabajo realizado, si el ritmo de trabajo es el adecuado para cumplir los objetivos definidos para el sprint en curso y tomar decisiones en base a ello.

Existen tres gráficas que permiten visualizar de forma simple el avance, pero en cualquiera de los casos la medición se hace en base a los puntos asignados a las historias de usuario, ignorando la cantidad de historias abarcadas.

• Burndown Chart: Esta gráfica muestra la cantidad de trabajo pendiente en función del tiempo, es decir, la cantidad de puntos que falta completar dependiendo del día del sprint.

• Burnup Chart: Esta gráfica es similar a la Burndown Chart, pero desde el punto de vista opuesto, mostrando la cantidad de trabajo realizado en función del tiempo, es decir, la cantidad de puntos que ya se han completado dependiendo del día del sprint.

• Flujo acumulado: Esta gráfica muestra el flujo de los puntos de las historias de usuario mientras pasan por las diferentes etapas del proceso de desarrollo. En este caso, se toman como referencia los sprints en su totalidad, por lo que la gráfica muestra el flujo durante toda la duración del proyecto.

En el tercer gráfico, que significa el estado QA?

Los puntos de las historias de usuario son aquellos que fueron definidos con Fibonacci u otra técnica de asignación no?

Algunas notas sobre este punto que ya manejaba y quizás les puedan servir para el Burndown chart del sprint

1. Propósito: Mostrar el trabajo restante sobre el tiempo (usado por el equipo para su propia gestión)
2. Responsabilidad: equipo de desarrollo (incentivado por el Scrum master)
3. Es actualizado normalmente después de cada reunión diaria.

Gráficas
En cualquier momento del Sprint el equipo puede analizar el progreso hecho y revisar si aún se puede cumplir el objetivo planeado al inicio de la iteración.

Burn down chart =Trabajo pendiente
Burn up chart = Trabajo que vamos completando

¿Es viable replicar este modelo de SCRUM en otras circunstancias que no sean desarrollo de software?

Hola:
Los gráficos en la ventana “Trabajo Pendiente” no se ve, en “Completado” tampoco…
¿Alguien sabe por qué y cómo poder solucionar?

Burn-Down chart gráfica de Trabajo Pendiente, está enfocada en el Sprint y su objetivo es terminar los puntos hasta completar y no tener pendientes.

Burn-Up chart o gráfica de trabajo completado, el objetivo es cumplir los puntos estimados en el sprint en su totalidad.

Gráfica de Flujo acumulado, se realiza con valores históricos de valores anteriores. Toma en consideración los distintos estados de los elementos del sprint, estos son Pendiente, En proceso, QA y completado.

Avance del proyecto
En cualquier momento se puede analizar el progreso del Sprint y verificar si aun podemos completar el objetivo del Sprint

Graficas

• Burndown Chart
• Burnup Chart
• Flujo Acomulado

No entiendo muy bien cómo se cuentan los puntos estimados y terminados realmente, supongamos que tengo una historia que es crear un formulario (9 puntos) , y en el primer día avanzamos sólo un 30% o supongamos la mitad, es decir que avanzamos pero no llegamos a terminarlo… Cómo debería anotar los puntos en el campo “real” ? Debería colocar la mitad de 9 ? debería colocar 0 porque la historia no se completó? debería colocar un 2… un 3 quizás? Me resulta un tanto extraño y abstracto esto de contar las historias en puntos… pero bueno supongo que no estoy terminando de entender la lógica.

Estimado profesor “en base” esta mal dicho, la forma correcta es “con base” 😄

Midiendo el avance del proyecto. El propósito de medir el avance de un proyecto Scrum es que el equipo pueda analizar el progreso y revisar si aún se puede cumplir el objetivo planeado al inicio de la iteración.

Los gráficos solo funcionan si clonan la plantilla que está el drive. No funcionan directamente en Excel

La idea de ir midiendo el avance del proyecto es que el equipo de desarrollo puede ir viendo a lo largo de la Sprint si se puede o no cumplir el objetivo del Sprint.

Gráfica de trabajo pendiente o Bourn Down Chart: 🚀

Un gráfico de trabajo pendiente a lo largo del tiempo, muestra la velocidad a la que se estan completando los objetivos. Permite extrapolar si el equipo podrá completarel trabajo en el tiempo estimado.

Usualmente el trabajo remanente (backlog) se muestra en el eje vertical y el tiempo en el eje horizontal. Muy util para realizar adaptaciones entre los sprints.

Si usamos sistemas como Jira este nos dará las gráficas y nos hará el trabajo mucho más sencillo. En este ejemplo podemos ver:

• Los puntos estimados para el Sprint que son 100.
• El de Sprint cuenta con 10 días de desarrollo.
• Tenemos dos líneas lastimada por el equipo y la real (trabajo día a día del equipo).
• Tenemos una columna de completado qué es la que se encarga de mostrarnos El Avance del equipo.
• Tenemos una columna de pendientes Qué es la que se encarga demostrarnos lo que todavía no se ha realizado.
• Al finalizar el Sprint en el día 10 podemos revisar la línea roja Qué es el estimado versus la línea azul Qué es el desarrollo real del producto.
• En tal caso que la línea azul (progreso real) no llegue a cero podemos definir o estimar las tareas que faltan para el siguiente Sprint.

Bourn Up Chart: 💚

Se marca una línea adicional (amarilla) la cuál es el objetivo al que queremos llegar.

• Momento en que la línea roja toca la línea amarilla hemos cumplido el objetivo del Sprint (en el caso de la gráfica lo completamos antes de tiempo estimado). Lo que nos puede dar tiempo de revisar oportunidades de mejora.

Gráfica de flujo acumulado: 😇

Está gráfica no la usamos en el día a día del Sprint, sino que lo hacemos en el histórico de los Sprints anteriores.

• En esta gráfica podemos ver todos los estados del progreso del Sprint (pendiente, progreso, QA y completo).
• En el caso de la gráfica la línea verde va creciendo en el tiempo, lo qué quiere decir que se van agregando historias en el Sprint.
• Debemos determinar en la gráfica cuánto tiempo que tarda una historia de pasar de un estado a otro (estado pendiente pasa a estado completo). Está medición de hace de forma horizontal dentro de la gráfica. En la gráfica podemos ver que el Sprint 3 cuando estaba en estado de progreso tardo 3 Sprints adicionales (está en el Sprint 6 cuando finalizo) en llegar al estado de completo, lo cual es demasiado tiempo ya que debemos encargarnos que las tareas que se definan en un Sprint se terminen en el mismo Sprint.
• Debemos identificar los cuellos de botella y eso es lo de terminamos en base a la distancia vertical que existe entre un estado y otro. Por ejemplo: En la gráfica podemos ver que en el Sprint 5 la distancia vertical entre QA y completo es bastante ancho, lo que quiere decir que hay bastantes puntos en QA en ese Sprint así que tenemos que analizar porque habían tantos puntos e identificar que fue lo que pasó en el proceso y porque se generó este cuello de botella.

Ejercicio de la pelota
La estimación en el primer sprint fue la más lejana de la practica, en los otros sprint dada la experiencia se fueron mejorando la estimación de rondas completas.
Esto se logró debido al tiempo de planeación que se toma en cada sprint para determinar cuál es la estrategia más óptima para realizar el proceso y también por la retroalimentación que se hacía al final de cada sprint para determinar en que se podría mejorar y que estábamos haciendo de forma correcta.

El progreso de un proyecto Scrum puede ser medido por un release burndown chart.

Veamos sus características más resaltantes:

El ScrumMaster debe actualizar este gráfico al finalizar cada sprint.

El eje horizontal del burndown chart muestra los sprints.

El eje vertical muestra la cantidad de trabajo pendiente por realizar al inicio de cada sprint.

Muy buena la explicación, pero pienso q hubiese sido genial q armara el excel desde cero, tomándose un poco mas de tiempo en el desarrollo de la grafica y no solo insertar los datos en una plantilla pre-configurada

Entendido y a ponerlo en práctica.

pondran el excel con los 3 graficos?

la plantilla compartida en el excel, no tiene la grafica de Trabajo completado

Paso este video que me ayudó a entender mucho mejor el burn down chart SE LOS RECOMIENDO !! https://www.youtube.com/watch?v=_7NJpxMT54U

Dentro de la metodología Scrum, un QA (Quality Assurance o Assurance Quality) se refiere a un miembro del equipo encargado de garantizar la calidad del producto desarrollado. Los QA desempeñan un papel esencial en el proceso de desarrollo ágil de Scrum al asegurarse de que el producto cumpla con los estándares de calidad y las expectativas del cliente.

Las responsabilidades de un QA en Scrum pueden incluir:

Pruebas de software: Los QA diseñan y ejecutan casos de prueba para verificar que el software funcione según lo previsto y que cumpla con los criterios de aceptación definidos para cada funcionalidad.

Revisión de código: Los QA pueden participar en la revisión del código fuente para identificar posibles problemas de calidad y asegurarse de que se sigan las mejores prácticas de codificación.

Automatización de pruebas: Los QA pueden desarrollar scripts de automatización de pruebas para agilizar la verificación de la funcionalidad del software a lo largo del ciclo de desarrollo.

Validación de requisitos: Los QA trabajan con el equipo de desarrollo y el propietario del producto para asegurarse de que los requisitos del usuario se comprendan y se implementen correctamente.

Gestión de problemas: Los QA pueden ser responsables de rastrear y gestionar problemas de calidad y defectos encontrados durante el desarrollo, asegurándose de que se resuelvan de manera oportuna.

Colaboración en retrospectivas: Los QA pueden proporcionar retroalimentación sobre el proceso de desarrollo en las reuniones de retrospectiva para mejorar continuamente el proceso.

En resumen, un QA en Scrum es un profesional que trabaja en estrecha colaboración con el equipo de desarrollo para garantizar la calidad del producto, identificar y resolver problemas de calidad y asegurarse de que el software cumpla con los estándares de calidad definidos. Su función es esencial para entregar un producto final de alta calidad en cada iteración del desarrollo ágil.

Trabajo pendiente -->burn downs,
Trabajo completado --> burn ups,
Flujos acumulativos -->Comulative flows

Yo si soy fan de trello

Esta Demostración en puro oro la verdad me costaba entender el porque de la necesidad de usar puntos en la estimación y no horas.

En ese caso de la Grafica de flujo acumulado, pienso que tambien serviria Kanban.

Otra cosa bueno de las metodologías agiles son las lecciones aprendidas, por lo que puedes tratar de entender el porque completaste más puntos en cierto periodo, para replicarlo en los otros peridos en los que se completaron menos puntos.
Agil no es hacerlo rapido es hacerlo flexible.

Empezar paso a paso.

Excelente tarde, quería saber como les fué con el ejercicio de las pelotas y sus conclusiones? Gracias

En la sección de “Recursos”, está mal escrita la palabra “Burn” en los diferentes tipos de gráficas. Saludos

¿Qué es un Diagrama de Flujo Acumulativo?
.

En el minuto 9.42 Gerardo habla de que la línea azul está en el SPRINT 6, sin embargo al revisar el gráfico, se ve que el eje “X” está midiendo los DÍAS y no los SPRINTS.
.
Diagrama de Flujo Acumulado: La Clave para Estabilidad Óptima del Proceso

.
Diagrama de Flujo Acumulado
El Diagrama de Flujo Acumulado es una de las analíticas más avanzadas para gestión Lean. Proporciona una visualización concisa de las tres métricas más importantes de tu flujo:
.

• Tiempo de Ciclo

• Rendimiento

• Trabajo en curso (WIP)

.
Su propósito principal es mostrarte el nivel de estabilidad de tu flujo y ayudarte a comprender dónde necesitas concentrarse para que tu proceso sea más predecible. Te proporciona una visión tanto cuantitativa como cualitativa de los problemas pasados y existentes y puede visualizar grandes cantidades de datos.

.
¿Cómo Leer un Diagrama de Flujo Acumulado?
El gráfico rastrea el número total de elementos de trabajo que se encuentran en las columnas de la sección En Curso en tu tablero Kanban cada día.

…

• Con un DFA puedes obtener una idea de cuánto tiempo dura el ciclo aproximado de tus tareas con una sola mirada.

• Esto es posible midiendo la distancia horizontal entre la línea superior de la primera etapa en el diagrama y la línea inferior de la última etapa antes de Hecho.

• La cantidad de días / semanas / meses que han pasado es el tiempo de ciclo promedio aproximado de las tareas de tu equipo para el período seleccionado.

• La distancia entre las líneas de un DFA te mostrará los problemas de tu flujo de trabajo.

Que poderosos son los gráficos para transmitir información

Excelente

Revisión gral del Backlog de historias del usuario + Expresión gráfica + Revisión de cuellos de botella

Gracias por los graficos

Muchas gracias, increíble explicacion, todo queda muy claro

Hola,
Versión actualizada de las tablas: Descargar Por favor, NO modificar el archivo. Vi que alguien había modificado las tablas para que funcionaran en Excel, sin embargo de la forma que las hizo la tendencia queda mal ya que tira a 0 cuando no se ha ingresado un valor.

burnup trabajo completado / down pendiente

Excelente explicación y buenos ejemplos!!!

no entiendo como cobrar aun cliente que quiere saber las horas de trabajo. Por lo general se cobra por hora.

No entiendo como hacer eso con estos puntos

Interesante la clase, sugiero poder tener visibilidad durante la explicación de las formulas…

Gracias

Medir avances del proyecto

• Se descarga si se puede o no cumplir con el objetivo del Sprint.

Seguimiento según las historias de usuarios por días, en base al día a día del Sprint.

Excelente

Excelente forma de medir el progreso y de darnos cuenta con datos cual es la performance del equipo

Muchas gracias !!

Gracias es muy interesante la información.

Plantilla Burndown en excel

No estan las graficas de pesta;a de “trabjo pendiente” y tampoco la de “completa”. Hay posibiidad de que suban nuevamente el archivo??

Gracias

El Excel nos sirve bastante como guía ya que nos indica datos reales y los gráficos son un apoyo visual.

hola buena tarde: no esta el archivo de las graficas; lo pueden subir por fa. gracias

Gracias por comopartir la herramienta

Hola.

En el documento de Excel, no está el BURNDOWN CHART, antes si estaba… podrían modificar el documento para que tenga ese gráfico, caso contrario no es posible analizar visualmente el avance del proyecto.

En el excel, está sólo la tercera gráfica, verdad?

Excelente perspectiva

solo la pestaña de flujo acumulado tiene grafica

Muy interesantes esas gráficas

Esta genial este formato!!! SOY EL PRIMER COMETARIO…

SIIIIII 😄

Buenas tardes,

Es posible tener acceso a la plantilla?, en la que descargue no me refleja completa

No se entiende uy bien la diferencia entre le burn down chart a el burn up chart, parecen lo mismo

La verdad no entiendo como funciona la asignación de puntos, veo que el máximo que pone es 15, pero no entiendo cuál es su criterio para otorgar esos puntos.

la mejor clase!

MIDIENDO EL AVANCE DEL PROYECTO
En el dia a dia o en todo el proyecto en general
Es para que el equipo de desarrollo si se puede o no cumplir el objetivo del sprint
Se hace en base a los puntos de historias de usuario.
Burn down chart - El objetivo es terminar los puntos y llegar a tener 0 puntos “pendientes” de historias de usuario en los días de sprint
Burn up chart - El objetivo es cumplir los puntos en su totalidad acumulandolos a lo largo de los dias de sprint

Solo la pestaña de flujo acumulado cuenta con grafica.

En cualquier momento del Sprint el equipo puede analizar el progreso hecho y revisar si aún se puede cumplir el objetivo planeado al inicio de la iteración.

Excelente recursos.

Muy prácticas las gráficas, excelente clase.

Herramientas interesantes!

buen curso

En la gráfica de flujo los valores horizontales aparecen en “Dia”, no deberían ser Sprint ???

Excelente

Estupenda explicación instructor Gerardo, por medio de estas graficas tengo más claro cómo se puede aplicar el sistema de puntos para determinar el progreso del sprint.

Super interesante, lo pondre en practica 😉