Indicators and reporting – iceScrum

Documentation This documentation applies only to iceScrum v7.
For old iceScrum R6, read the documentation or migrate.

iceScrum automatically produces indicators at the sprint, release and product level. Scrum indicators such as the burndown chart, burnup, parking lot, cumulative flows, etc. are available.

Burnup chart


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.

Cumulative flow chart


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!

Parking lot chart


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.

Velocity chart


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!

Velocity vs Planned Velocity chart

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!

Release notes and sprint notes

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 storiesdefects 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.


Try it for free now
All you need for your Agile project management