A burndown chart tracks progress of remaining work over time.

In the simplest form it has one curve which follows the evolution of the recorded remaining work over time.

If things go well, the curve is expected to decrease at a steady pace toward zero. Thus, the two things to look for are the trend of the curve and where it will reach the x-axis according to its global shape so far.

A burndown chart may include an additional line representing the «ideal» world where the line decreases uniformly from the starting point to zero at the end of the observed period. If you want a more accurate reference curve, you can use team availabilities.

For a sprint, the vertical axis is the amount of remaining work, which can be the total task remaining time or the total story points that remain. The horizontal axis is time, measured in days.

This chart is very efficient to inspect progress in terms of the effort that remains to provide. It can help detect issues early and remove an obstacle or adapt the scope accordingly. That is why it is included in iceScrum and so widely used in the agile world.

However, it works well only for a pre-defined scope that is not intended to vary significantly. This is very often the case of story points for a sprint, but depending on your context it may not be the case for the task remaining time.

In iceScrum, a Burndown chart is also available at the project and release levels as bar charts but they are mainly there for historical reasons, as a project or release scope is actually intended to vary as we discover how the product should evolve.

A good rule of thumb to apply is that when you would like to use a Burndown but the scope varies over time, a Burnup chart is probably a better choice!

El gráfico burn up (o burnup) rastrea el progreso hacia la finalización del proyecto. En la forma más simple del gráfico hay dos líneas:

• Una línea de trabajo total (la línea de alcance del proyecto)
• Una linea de trabajo terminado

El eje vertical es la cantidad de trabajo, y se mide en unidades personalizadas para su propio proyecto (aquí elegimos los puntos). El eje horizontal es el tiempo, medido en iteraciones (de una semana).
En cada iteración puede ver la cantidad de trabajo completado y la cantidad total de trabajo. La distancia entre las dos líneas es, por lo tanto, la cantidad de trabajo restante. Cuando las dos líneas se encuentran, el proyecto estará completo. Esta es una poderosa medida de qué tan cerca está de la finalización del proyecto.

¿Por qué usar un gráfico de burnup?

El objetivo de cualquier gráfico es la comunicación, un gráfico de burnup muestra claramente el trabajo completado y el alcance del proyecto. Es una herramienta efectiva para comunicar a las partes interesadas del proyecto y a los clientes cómo las solicitudes de características adicionales que están solicitando afectarán la fecha límite y, al mismo tiempo, les asegura que se está haciendo un buen progreso.

Un gráfico de flujo acumulativo es un gráfico de área que representa la cantidad de trabajo en un estado determinado (terminado, en progreso, planificado, aceptado, sugerido, estimado) en la línea de tiempo de su entrega, para cada iteración y en función de sus historias. Las líneas se mueven hacia arriba y hacia abajo siguiendo el trabajo realizado durante cada día/iteración. En un solo vistazo, puede encontrar algunos datos importantes sobre su proyecto.

Cuando las líneas estimadas (azul) y terminadas (verde) se cumplan, podemos decir que el proyecto estará terminado y el producto entregado. Manteniendo el alcance equivalente a lo que es en el momento en que mira el gráfico, puede aproximadamente imaginar cuándo sucederá este cruce. También puede tener una idea del WIP en su proyecto al medir el número de historias entre la línea verde y azul. Si sus líneas azules y verdes se alejan cada vez más, puede razonablemente decir que algo anda mal con el proyecto (se planean demasiadas historias, por ejemplo).

De hecho, el diagrama de flujo acumulado es un gráfico muy útil para tomar la temperatura de su proyecto en desarrollo de varias maneras.

El gráfico de parking lot es un gráfico basado en características que resume el estado del proyecto al mostrar el logro de cada una de sus características en porcentaje. Cada porcentaje representa la cantidad de historias asociadas a una característica que se ha logrado.
The parking lot chart is a feature driven graph that summarizes the project status by displaying the achievement of each of your feature in pourcentage. Each percentage represents the number of stories associated to a feature that have been achieved.

Los gráficos de parking lot envuelven las características en grupos funcionales y luego estos grupos en áreas funcionales para ilustrar mejor el progreso general en comparación con las áreas de negocios.

El gráfico de velocidad muestra la suma (en puntos) de las estimaciones de las historias entregadas para cada iteración. Cada tipo de historia (historia de usuario, historia de defectos e historia técnica) se muestra en esta suma con un porcentaje y representado por un color diferente. El total es siempre equivalente al 100% ya que es la cantidad total de puntos de la historia lanzada durante el sprint.

Este gráfico le permite ver la velocidad de su equipo. Una buena velocidad debería ser una creciente, es decir, más puntos logrados en cada iteración. Si su velocidad aumenta, puede analizar esta progresión diciendo que su equipo se está sintiendo cada vez más cómodo con el proyecto. Si la velocidad reduce (generalmente es bastante brutal) debe ser para algunos problemas técnicos o malentendidos en el proyecto.

Como dicho antes los colores representan 3 tipos de historias: historias de usuarios, historias técnicas, historias de defectos. Cuanto más verde se obtiene en su gráfico de velocidad, mejor es! Además, es preferible tener un gráfico de velocidad que aumenta lentamente pero solo con historias de usuario que más puntos con muchos puntos de gestión de defectos. De hecho, si obtiene demasiados puntos de historias de defectos, ¡significa que pasas demasiado tiempo resolviendo problemas!

Este gráfico muestra la variación entre lo que su equipo ha logrado durante las últimas iteraciones (la velocidad del equipo, en verde) y lo que fue planificado (en puntos) por el equipo (la velocidad planificada del equipo, en azul). La Velocidad planificada es el total de puntos de las historias planificadas en la iteración en el momento de su activación.

En una gestión de proyecto perfecta, ambas líneas deberían encontrarse al final de cada iteración. Si no es el caso, puede intentar averiguar por qué.

Quizás las historias que logramos fueron subestimadas en términos de puntos (y/o tiempo)? Nos tomó más tiempo para lograrlas y no pudimos trabajar en otras, por lo que deberían haber contado para más puntos y debería haber menos puntos estimados en la iteración (lo que significa tener menos historias en el plan de iteración). ¿O tal vez enfrentamos problemas de equipo como enfermedad o salidas/llegadas en el equipo y afectó la velocidad del equipo?

De todos modos, este gráfico es otra información significativa disponible para usted en iceScrum. ¡Y debería ayudarle a mejorar su gestión de proyectos!

Puede usar iceScrum para generar automáticamente registros de cambios para una entrega o una iteración. Puede acceder a esta función desde la vista planning, seleccionando la entrega o la iteración, y luego seleccionando la pestaña de notas de la entrega o la pestaña de notas de iteración. Esto generará todas las historias incluidas en el cuadro de tiempo seleccionado en un texto formateado, listo para copiar/pegar.

iceScrum proporciona una plantilla de notas de sprint para HTML y MarkDown. ¡Le recomendamos que los edite según sus necesidades o que cree sus propias plantillas! Las plantillas de notas le permiten definir secciones para diferentes tipos de historias, generalmente historias de usuarios, de defectos y técnicas. También puede seleccionar historias en una sección de notas de entrega/iteración mediante el uso de etiquetas (tags).

El campo de plantilla de historia le permite definir qué información de la historia debe incluirse en las notas de la entrega.

Algunos campos permiten usar variables para hacer que el contenido de las notas de la entrega sea dinámico:

• Plantilla de historia: información de la historia, información de la iteración, información de la entrega, información del proyecto
• Encabezado: información de iteración (solo para las notas de iteración), información de la entrega, información del proyecto
• Pie de página: información de iteración (solo para las notas de iteración), información de la entrega, información del proyecto

${serverUrl} // URL of your icescrum server
${baseUrl} // shortcut for building permalinks = ${serverUrl}/${project.pkey}.
//It can be used as ${baseUrl}-${story.id} to create a permalink to the corresponding story.

${story.id}
${story.name}
// or more generally
${story.[id,
        name,
        description,
        notes,
        origin,
        effort,
        rank,
        affectVersion,
        suggestedDate,
        plannedDate,
        estimatedDate,
        inProgressDate,
        doneDate,
        comments]}

${sprint.id}
${sprint.goal}
// or more generally
${sprint.[id,
          goal,
          startDate,
          velocity,
          plannedVelocity,
          endDate,
          deliveryVersion,
          orderNumber,
          index]}

${release.id}
${release.name}
// or more generally
${release.[id,
           name,
           startDate,
           endDate,
           orderNumber]}

${project.id}
${project.name}
// or more generally
${project.[id,
           name,
           pkey,
           description,
           startDate,
           endDate]}

La generación de notas de iteración y entrega también están disponibles a través de APIs Web iceScrum, para que pueda automatizar su proceso de entrega.

Lee la sección correspondiente en la documentación API.