A burn up chart, or burnup chart, tracks progress towards a projects completion. In the simplest form of burn up chart there are two lines on the chart:
– A total work line (the project scope line)
– A work completed line

The vertical axis is the amount of work, and is measured in units customized to your own project (here we chose the points). The horizontal axis is time, measured in sprints (of one week).
At each sprint you can see the amount of work completed and the total amount of work. The distance between the two lines is thus the amount of work remaining. When the two lines meet, the project will be complete. This is a powerful measure of how close you are to completion of the project.

Why use a brunup chart?

The goal of any chart is communication, a burn up chart clearly shows work completed and project scope. It is an effective tool for communicating to the project stakeholders and clients how the extra feature requests they are asking for will affect the deadline, and at the same time for reassuring them that good progress is being made.

A cumulative flow chart is an area graph that depicts the quantity of work in a given state (done, in progress, planned, accepted, suggested, estimated) on your release timeline, for each sprint and based on your stories. The lines are moving up and down following the work achieved during each day/sprint. In a glimpse you can find a few important bits of information about your project.

When the estimated (blue) and done (green) lines will met, we can pretty much say that the project will be finished and the product delivered. Keeping the scope equivalent to what it is at the moment you watch the chart you can roughly imagine when this cross will happen. You can also have an idea of the WIP on your project by measuring the number of stories between the green and blue line. If your blue and green lines get increasingly far from each other you can reasonably say that something is going wrong with the project (too many stories planned for example).

In fact the cumulative flow chart is a very useful chart to take the temperature of your on going project in various ways!

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.
Parking Lot diagrams roll-up features into functional groups and then these groups into functional areas to better illustrate overall progress against business areas.

The velocity chart displays the sum of the estimates (in points) of delivered stories for each sprint. Each story type (user story, defect story and technical story) is shown in this sum with a percentage and represented by a different color. The total is always equivalent to 100% as it is the total amount of story points released during the sprint.

This chart allows you to see the velocity of your team. A good velocity should be an increasing one, i.e. more points achieved for each new sprint. If your velocity increases you can analyse this progression by saying your team is getting more and more comfortable with the project. If the velocity slows down (generally it is quite brutal) it must be for some technical issues or misunderstandings in the project.

The colors represent 3 types of stories as said before: user stories, technical stories, defect stories. The more blue you get in your velocity chart, the better it is! Also, it is preferable to have a slowly increasing velocity chart but with only user stories than more points with a lot of defect management points. Indeed, if you get too much defect stories points it means you spend too much time on resolving issues!

This chart displays the variance between what your team has achieved during past sprints (the team’s velocity, in green) and what was planned (in points) to be done by the team (the team’s capacity in blue). The capacity is an estimated velocity calculated according to the previous sprints. Basically, it is a projection of the work that will be achieved based on the previous sprints’ velocity.

In a perfect project management, both lines should meet at the end of each sprint. If it is not the case, you can try to find out why.

The stories we achieved were maybe underestimated in term of points (and/or time)? We took more time to achieve them and could not work on others, so they should have counted for more points and there should be less points estimated in the sprint (meaning having less stories in the sprint plan). Or maybe we faced team problems like sickness or departures/arrivals in the team and it affected the team capacity?

Anyways, this chart is another meaningful information available for you in iceScrum. And it should help you enhance your project management!