Do You Know the Types of Agile Scrum Charts for Showing Progress?

When to Use Each Scrum Chart?

Often, I have witnessed agile project teams that do not understand the benefits of the Agile Scrum charts and their value. There is confusion about when to create them, what to make of them and even what measures to use. This post is intended to provide some insight into the value of the Agile Scrum charts, the various types of charts, and the best use for each. After reading this, I encourage other Agile practitioners to share your thoughts and any other charts that would be beneficial. I’ve seen these charts used in different formats as well. So please do share.

The Agile Scrum Framework

Before I jump into the Agile Scrum charts, I think it is important to provide a brief refresher on the Agile Scrum framework and how a product is decomposed to the task level. This is a high level description of Agile Scrum — just enough to provide some context for the main topic of the post. For those of you that are comfortable with the Agile framework, you can skip to the next section.

Agile Scrum is a specific type of agile project management that focuses on delivering value as “potentially shippable” components of capability in time-boxed and iterative increments (a.k.a., Sprints). The recommended duration for a Sprint is about two to six weeks. The requirements in Agile are stored in what is called a Product Backlog. Each requirement is called a User Story because it is written from the user perspective. Prior to each sprint, a sprint planning session is conducted, where the team and the product owner get together to determine how many of the next top level user stories in the product backlog can be completed in the next sprint. The collection of user stories for each sprint are called the Sprint Backlog. A collection of sprints can be grouped into a release so that the overall structure is like this:

  • Product Backlog
  • Release Backlog
  • Sprint Backlog

The development team must further decompose the stories in each sprint into tasks. Additionally, the team might want to develop additional artifacts and design documents to support the completion of the story or task. So the Sprint decomposition structure might look something like this:

  • User Stories (usually measured in story points)
  • Tasks (usually measured in level of effort / hours)
  • Note: Additional Systems Engineering artifacts can be created to clarify development needs

Notice that I’m completely skipping over Themes and Epics, which are essentially larger stories. Not enough time here to get into all of that.

Got it! Good! Now to the good stuff — the charts.

Sprint Velocity Chart

The development team plays a key role in determining how much work they can commit to completing in every sprint. But in order to do this, the team needs a way to measure the amount of effort required to complete a sprint. The amount of work required to complete a sprint is measured by story points. Story points are a relative unit of measure so that 1 story point is less effort than 2 story points, which is less than 3 story points. Remember, though, that story points can be measured in different ways. For example, you can use the Fibonacci series to measure relative effort. The important thing to take away here is that story points are used to measure relative complexity of user story.

Over time, the team gets a general idea of how many story points they can complete in any given sprint (assuming that the sprints are consistent in duration). This is the team’s velocity. But in order to know this, the team needs to keep track of the velocity for previously completed sprints. This sample chart shows the value of maintaining such information. As you can see, the team can quickly see that their average velocity is somewhere around 15 story points. This is valuable information when trying to determine how much work you can accept in a future sprint.

Sprint Velocity Chart

Sprint Velocity Chart (for each Sprint in

Burn Down Charts

Burn down charts are used to show the amount of work completed against the amount of work remaining. One of the best reasons to use burn down charts is that you can use it to quickly predict when you will finish the work based on your burn rate. I use two kinds of burn down charts — the Release Burn Down Chart and the Sprint Burn Down Chart.

Release Burn Down Chart

This is a sample Release Burn Down Chart. It is generated after the completion of each Sprint. I find the information visually compelling to quickly show the business and the team where we are in terms of the number of story points completed after each sprint, and to show how many more story points remain to complete the release. Note that in this example, during the sprint planning session for Sprint 3, ten additional story points were added to the release backlog, which increased the total number of release story points from 90 to 100. (Although adding stories scope to a release or sprint is not encouraged mid-flight, it is sometimes unavoidable. The market conditions might dictate, for example, that a specific feature must be put in sooner in order to keep up with demand or a competitor. The key is communication in these situations.)

Release Burn Down Chart

Release Burn Down Chart Sample

Sprint Burn Down Chart

The Sprint Burn Down Chart is really intended for the development team and the Scrum Master to know how the team is doing on the completion of the sprint. It is updated daily if possible. This is a great tool to see if the team is falling behind, and if so, to investigate the reasons why. The sample Sprint Burn Down Chart shows actual progress (red) against the projected burn down which is just a linear projection of burn rate based on the number of days (blue).

Sprint Burn Down Chart Sample

Sprint Burn Down Chart

What Kind of Charts Do You Use?

Do you use the charts in a different way? Or do you use other charts? Share your thoughts with us.