Additional Release Burndown Charts

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.

Traditional Release Burndown Chart

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.

Release Burndown Bar Charts

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.

Parking lot chart

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.

Prioritizing Features using Kano Model

The Product Backlog provides a collection of features that the Product should ideally implement. But not every feature has the same priority. Some of the features are more important than others and of course, the Product Owner doesn’t go around picking random features while prioriterzing the features.

There are various models and in this example, we will explore the Kano Model.

The Kano Model

As per Nariako Kano’s model, the features could be broadly categorized into 3 categories.

  • Thresholds/Must Have Features These represent the minimum set of features that should be present to meet User expectations. Improving the must have features beyond a limit would have little impact on the customer satisfaction. For example, for accommodation, a minimum requirement of User would be a clean room with basic ammenities.
  • Linear Features Features which increases customer satisfaction as it increases is known as Linear Features. This includes the size of the room or bed, freebies in the room etc.
  • Delighters Delighters on other hand are features which adds to the premium quality of product, often adding greatly to customer satisfaction. These could include private pools. These are features which the Customer might not quite miss if not present, but would be delighted if present.

Now that we have understood how we would like to group the features, the process of actually grouping them begins. As per Kano, this could be done by asking two questions per feature to the user group.

  • Assuming the feature is present, also known as Functional question
  • Assuming the feature is not present, also known as Dysfunctional Question.

The answers are questions are typically collected as

  1. I like it that way
  2. I expected it that way
  3. I am neutral
  4. I can live with it that way
  5. I dislike it that way

The answers could be mapped to 3 feature groups using the following table.

The answers from the user groups (typically 20-30 users) are aggregated and their distribution could be observed to determine the priority group.

The responses with high values are considered.

This was one approach for User Story Prioritization. In the next post, we will explore Relative Weighting approach.