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!

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 burnup 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 then) 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 each 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 green 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 Planned Velocity in blue). The Planned Velocity is the sum of the story points of the stories planned into the sprint when it was activated.

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 velocity?

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

You can use iceScrum to automatically generate changelogs for a release or a sprint. You can access this feature from the planning view, by selecting the release or sprint, and then by selecting the release notes tab or sprint notes tab. This will output all the stories included in the selected time box into a formatted text, ready to copy/paste.

iceScrum provides out of the box release and sprint notes template for HTML and MarkDown. We strongly encourage you to edit them to suit your needs or to create your own templates! Notes templates let you define sections for different types of stories, typically user stories, defects and technical stories. You can also select stories in a release/sprint notes section by using tags.

The story template field lets you define which information of the story should be included in the release notes.

Some fields allow using variable in order to make the release notes content dynamic:

• Story template: story information, sprint information, release information, project information
• Header: sprint information (only for sprint notes), release information, project information
• Footer: sprint information (only for sprint notes), release information, project information

${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]}

Sprint and release note generation are also available through IceScrum Web APIs, so that you can automate your release process!

Check out the corresponding section in API documentation.