To say that Burndown Charts are significant for any Agile teams would to state the obvious. Anyone who has worked in an Agile project could tell you how useful these charts are in understanding overall progress of the project.
A typical burndown chart during development of the project might look as the following.
The Blue line indicate the ideal or desired completion of work, while the Red line indicate the actual completed work. The vertical axis indicates the total story points while the horizontal axis indicates the time axis.
As observed in the chart below, there is few things curious here. By the 3rd iteration, the team manages to complete about 20 User points and seems to be pretty much on the track, however in the next iteration, the pending work seems to be have suddenly increased. This seems to happened again in the 6th Iteration. So did the team fail to do any work ? Or was there new User Stories added ? It could also be the case where the team re-estimated some of the User Stories.
Similarly, what is not obvious in this chart is that during the 6th iteration, User managed to complete 10 User Points, but at the same time, Product Owner decides to remove User Stories worth 10 points from the backlog.
Burndown Bar Chart
While the traditional burn charts provides a lot of information, there is one place it is found lacking. More often than not the scope of the project could expand(or shrink) during the course of the development. The Project Owner could add more users stories (or remove) to the backlog. This could happen as an impact of market or as the understanding of the features expand. Furthermore, the team might have better understanding of some of the User Stories and would have re-estimated them. Both these activities could siginificantly affect the remaining work.
The traditional burn charts fails to indicate this expansion of work clearly. This is where a Burndown Bar Chart would come in handy. At this point, I should point that this is not exactly replacement of traditional burndown chart – but additional charts which could provide more clarity to the progress. In this case, the Bar chart would provide more clarity about velociy and scope changes.
A typical Burndown Bar chart might look like the following.
Each bar represents the amount of work that is left in the release prior to start of iteration. During the iteration team would work on various User Stories and most of them would be ideally completed. The completed work is indicated by lowering the top of the bar for the next iteration. The difference between two adjacent bars (iterations) indicate the velocity of the proceeding iteration.
When the Product adds or remove User Stories to backlog, the scope change is reflected by lowering or raising the bottom of the bar. Similiarly, if the team re-estimates the work, the top of the bar is lowered/raised.
In the graph below, the Product Owner adds User Stories worth 30 User Points in the 3rd iteration. In the 4th Iration, another 40 User Points worth User Stories are added to the backlog. This is indicated by lowering the bottom of the bar.
During the 6th iteration, the Product Owners decides to remove User Stories worth 10 User Points. This is indicated by raising the bottom of the bar.
This an useful way to indicate the scope changes and supports the traditional Burndown chart by adding more clarity to it. This ensures the stake holders understands why the burndown chart behaves as we discussed earlier.
Parking Lot Chart
The Parking Lot Chart is yet another representation of the remaining work. This provides a birds-eye view of the work remaining.
As seen in the image above, the Parking Lot Chart contains a group of rectangles. Each of rectangle is annotated by
- Theme
- Number of User Stories in the theme
- Total User Points in the Theme
- Percentage of completion of stories in the Theme
The intention behind the graph is to compress a lot of information in a smaller space and thus providing a high-level view on the progress of the project. The representation is based on themes, which is the grouping of similiar User Stories.
The Boxes could be colored to indicate whether the work remaining in the theme is on schedule or falling back in the schedule and needs attension.
Summary
As seen, there are various chart which could be added in addition to the traditional burndown chart to help the stake holder understand the progress of the project. One could also innovate and merge some of the charts together. For example, you could modify the traditional burndown chart to include the burndown bar chart representation as well so that you do not need to maintain two separate graphs (rather maintain a single merged version).
Of course there could other useful graphs as well which could indicate the progress of the chart in an useful, and we will continue to explore them in the posts soon.
ByteLanguage.Net 