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.


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.

Technical Debt Quadrant

In a practical corporate software development scenario, there are times when you have (willingly or otherwise) to give up to trade-offs and compromises  especially when the deadlines looms over you or, in worst case, you are LAZY !!. You might be prompted to choose a less than optimal solution due to situational constraints, which might lead to technical debts. But how would one convince the stakeholders (or may be himself) that you are not entirely wrong in opting for the selected solution ? How do you categorize technical debts

Martin Fowler had suggested a Technical Debt Quadrant which comes pretty useful in vindicating the trade offs by categorizing the situations or the intention with which we opt for debt.


The technical debt quadrant is quite easy to use and is especially useful when addressing a non-technical audience (stakeholders) about the trade-offs chosen. It can also act as guidelines for team (and product owner) when the deadlines are looming and trade-offs are required.

A Prudent-Deliberate Quadrant is a ideal situation wherein the team/developer has evaluated the alternatives and picked the choice completely conscious of the implications to achieve a specific business goal.They are aware that they would need to repay the debt at some point and has a plan of action for the same. This is where the team would ideally like to be when encountered with a technical debt. At the opposite end of the spectrum is a Reckless-Deliberate quadrant, which should be avoided at all cost. It implies that the developer/team understands the implications of the actions, but choose to opt for same citing avoidable reasons/excuses.

The Prudent-Inadvertent quadrant belongs to the class of hard working team who had the best intentions, but choose a different solution when a better one was available. Considering their keen interest for improvement and intention, these men represent a team who will improve over time. The last of the quadrant, the Reckless-Inadvertent group usually consists of who are inexperienced and doesn’t know the best practices. It was their ignorance which caused the debt, which is, to an extend acceptable.

On any day, a Prudent-Deliberate Quadrant is a scenario that the stake holders might not mind. However, all other types of scenarios needs to avoided.

StarFish Retrospective

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”

– 12th Principle, Agile Manifesto

It doesn’t need any explanation why Retrospectives are important in any scrum team. Question is, how can we make Retrospective Sessions more effective.

I was in conversation with a friend recently and one of the things he said he is running into trouble with is that the team members attempt to blame each other rather than getting to root of issues during retrospective.

To start with, key lies in making it more transparent. That doesn’t mean you need to document and publish it to anyone outside the team to view it. That is effectively an anti-pattern that plagues the success of retrospective. Unless the team members believes that what happens during the retrospective lies within the team, they wouldn’t be open with their opinions. This is the same reason why Line-Managers should be kept away from such meetings.

Care should also be taken to ensure the meeting doesn’t end up as a blame game, which is why the role of Scrum Master becomes critical, in the way he facilitates the meeting. The idea should be generate positive energy and responsibility, rather than a blame game that ends up depressing and energy draining.

Sprint Retrospective

Sprint Retrospective’s are usually revolved around 3 key questions

  • What went well ?
  • What did not go well ?
  • What can be improved ?

StarFish Retrospective

If the Scrum Master feels the questions are too broader for team to answer, he could employ exercises like the StarFish in the retrospective. The Starfish focuses on 5 Questions, instead of 3.

  • Stop Doing : Focus on things which are not doing any benefits for the team, and rather is getting on the way
  • Start Doing : Focus on new things which can add value to team
  • Continue Doing : Recognize things which is working well, and team should continue doing.
  • Do more often : Recognize things which is working well for team and could do team more good if done more frequently
  • Reduce Doing : Recognize things which is working well, but could reduce the frequency a bit.

The key however lies on finding the root cause, for example for things that you have chosen to stop doing completely. The team need to understand why it is not working. For this the Scrum Master could employ methods like the 5 Whys.

5 Why’s

5 Why’s is a root cause analysis technique that focuses on getting to the root of any problem by repeatedly asking “Why”. Each answer would form the basis of next question. You could read more on the 5 Whys in Wikipedia.

Scrum Vs Kanban

Agile and Scrum has been ruling the Software Development industry for quite a time now, at same time, slowly, but surely, Kanban is finding itself a strong foothold in the industry. So what is Kanban and how is it different from Scrum ?

Much like Scrum, Kanban is a tool for process improvement that provides you rules and constrains to effectively improve your process in the long run. Agile Methods such as Scrum and Kanban tend to be more adaptive (less rules to follow) than being prescriptive (more rules to follow). Relatively, Kanban is more adaptive than Scrum.


One of the key requirement of using any Process Tool is to ensure you adhere to the constraints associated with the tool.  Tools such as Scrum are minimalistic enough and if you were attempting to compromise on features such as Time-bound iterations and Daily Stand-ups, then it is better not to use the tool at all. These are the features/constrains which directly or indirectly makes the tool efficient.

Quite often, teams across the world end up adopting one Process Tool and adding features of others to it, while retaining the constraints of the original.

My attempt in this post would be to compare some of these constrains and it’s implementation in both Scrum and Kanban.

1. Prescribed Roles

Scrum prescribes 3 basic roles –

a) Product Owner – Responsible for setting priorities of tasks in the Product backlog

b) Team – Responsible for implementation

c) Scrum Master – Responsible for removing impediments and provide process leadership.

Kanban, on other hand doesn’t subscribe any roles. Teams can however, adopt roles, but only if they see any value to it.

2. Time Bound Iterations

Scrum roots for time-bound iterations with each sprint comprising of 3 basic phases – Planning, Implementation and Retrospective.


Planning Phase – During this phase, the forthcoming iteration is planned. Teams pulls out specific number of tasks from the product backlog based on the priority set by the product owner.

Implementation – Having defined the scope of iteration in the previous stage, the team gets cracking on the tasks in hand.

Retrospective – Team provides a demo of the work products of the sprint to the relevant stake-holders. The Product owner may choose to ship the work product to the business client. They also discusses the pros and cons of the concluded sprint and seek ways to improve.

Kanban, on other hand, doesn’t evolve around time bound iterations. The team choses its own feedback loop on when to plan, improve process and release. For example, Team could decide to release a work product every Tuesday or could very well say, we would release it only when we have something useful.

Scrum also focuses on having Daily Stand-up meetings where in, team would come together and provide an update of the tasks they are working on ( What they did previous day, What they intend to do on the day ).

Getting a feel that Kanban is more or less Ad-hoc ? Don’t worry, things are about to change.

Work Flow Task Items

Let’s have a look at the work flow of Scrum and Kanban through the representation of Progress Board – Called Scrum Board in Scrum and Kanban Board in Kanban.



The first impression on both board would give you is “they are exactly the same !!”. Well, Almost !! The difference is the number in the braces near the TODO and BUSY headers in the Kanban Board.

Scrum uses Velocity to measure the efficiency of sprint. It controls the WIP (Work in Progress) using a time based model by limiting the number of items in each sprint based on the velocity agreed by the team. On other hand, Kanban chooses to limit the WIP by limiting the number of items in each work flow state. In the example board shown, the maximum task items that can be in the busy state is 3.

Kanban uses “lead time” as a metrics for measuring and improving efficiency of the system. Lead Time is the average time taken for a task to move across the kanban board. For the purpose, teams using Kanban, tends to break down tasks to similar sizes. The feedback loop would help team in identifying and improving the lead time.

While estimation is not a forte required in Kanban System, “Lead Time” can be an efficient resource to depend on if the team is asked to estimate. Scrum uses a more formal method, called Planning Poker, for estimation.

Changes during Iterations

Scrum resists changes to spring log once team has committed to a sprint, even if the Product Owner holds a task of high value. Once the iteration has started, the only thing Product Owner can do is change the priority of the task and ensure it gets listed in the next sprint.

Since Kanban isn’t based on time bound iteration, it allows Product Owner or Customer to change the priorities at any time. The limitation comes in the form of WIP limit in the TODO list. The customer would have to take one item down to add another.

Other Differences

Other noticeable features which differentiate Scrum and Kanban includes Scrum’s emphasis on cross-functional teams, though one doesn’t always find it a developer testing. But the idea is, if at any time, testing becomes a bottle-neck, the developer should be able to lend a hand. This isn’t the case with Kanban, which doesn’t lay emphasis on team composition. The teams could be cross-functional or specialists for the jobs.

Another significant difference between the two tools is the way the task board is handled. Scrum resets the board after every sprint. After every sprint, all the task items are removed from the scrum board and fresh items are added to the extreme left column. Kanban, on other hand is an on-going process and doesn’t bother to reset the board at any point of time.


As one can notice, there isn’t much of the difference between Scrum and Kanban tools, though Kanban is slightly more adaptive than Scrum. It is more suitable to teams where the task priority could change frequently allowing the team to respond to customer requests within minimum time. With minimum constrains imposed, Kanban tends to become ad-hoc if not properly maintained. Scrum, on other hand, is more suitable for teams where Customer could commit to a sprint. A sudden change in priority could derail the entire sprint or would require the customer to wait for the sprint to complete. Both process tools has its own pros/cons and it is up to the teams to implement the basic rules to ensure the purpose of tool is served.

Both Scrum and Kanban is empirical in the sense, both expect the team to experiment with the process and customize it. If the scrum team has to experiment with velocity and sprint duration, the kanban team has to experiment with lead time and WIP Limits. Both tools provides the teams with the basic rules to govern the process and expects the team to improve their development process using continuous and empirical process optimization.


(1) Case Study by Mattias Skarin.