What a Burn down Chart Can Say

From :http://www.methodsandtools.com/archive/scrumburndown.php

What a Burn down Chart Can Say

There are only two lines drawn in Burn down chart, but the situation they describe might have different reasons.

Ideal Team

Such diagram indicates the great team able to organize itself. The team is not over-committing and finished the spring backlog on time. The team is also able to estimate capacity correctly. No corrective action is necessary in such case.

Great Team

Such progress might be observed on charts of experienced teams. The team has completed work on time and met the sprint goal. They also have applied the principle of getting things done, but the most important is they have adapted a scope of the sprint backlog to complete the sprint. At the end the team has a possibility to complete some additional work.

In the retrospective, the team should discuss the reasons of late progress in the first half of the sprint and solve issues so they are better in the next sprint. The team should also consider the capacity that they are able to complete.

Nice Team

This is a typical progress that can be observed in many experienced agile teams.

The chart says again that the team was able to complete their commitment on time. They adapted the scope or worked harder to complete the sprint. The team is self-reflecting.

The team should discuss change of plan immediately as they see the progress has been slowing down from the beginning of the sprint. Typically it is suggested to move a low priority item from the sprint backlog to the next sprint or back to the product backlog.

Boom. It Is Too Late.

This burn down chart says: "You have not completed your commitment".

The team has been late for the entire sprint. The team did not adapt the sprint scope to appropriate level.

It shows that the team has not completed stories that should have been split or moved to the next sprint. In such situation the capacity of the next sprint should be lowered. If this happens again, corrective actions should be taken after a few days when slower progress is observed. Typically, lower priority story should be moved to the next sprint or back to the product backlog.

Boom. Too Early.

The team finishes its work sooner than expected. The stories were implemented, but the team didn’t work on additional stories even it had the capacity to do it.

The stories were probably overestimated, therefore the team finished them earlier. Also the velocity of the team has not been probably estimated correctly.

Let’s Have a Rest

The team with such progress has a problem. The problem is either the team committed to less than they are able to complete or the product owner does not provide enough stories for the sprint.

The reason might be also an over-estimation of complexity, which ends up in completion earlier than expected at the beginning of the sprint.

Oh, Management Is Coming!

The team is probably doing some work, but maybe it does not update its progress accordingly. Another reason might be that the product owner has added the same amount of work that was already completed, therefore the line is straight.

The team is not able to predict the end of the sprint or even to provide the status of the current sprint.

Such team should be stopped after two or three days that shows a flat the line of progress and should immediately apply corrective actions.

Do Your Duties

The team is non-functional on many levels. To fix this situation the team should restart. Restart from scratch by training and do a retrospective to figure out why this is happening.

Zero Effort

A chart like this indicates that stories or tasks were not estimated during the sprint planning meeting and the sprint has not officially started yet.

To fix this situation, team should immediately arrange a planning meeting, estimate the user stories, include them in the sprint according to their velocity and start the sprint.

Up to the Sky

The first sprint typically looks like that. It is good source of knowledge because the team has failed significantly and it is highly visible.

Stories or tasks were added into the sprint backlog every day without any progress recorded. Another reason might be that tasks were re-estimated constantly during the sprint.

The mistake is that the team did not identify the problem that the chart displays.

The sprint backlog should be reevaluated and rearranged immediately. The coach might be helpful, as an experienced Scrum master and product owner should often facilitate this situation.

Bump on the Road

The team has not started sprint correctly. They added stories after the sprint had started. It is positive that they recognized that planning is missing planning, it is however too late. The team should be careful about the capacity estimation as planning happened in the middle of the sprint, not before it.

In such case it is suggested to restart the sprint, even within a shorter timeframe.

Progress from Long-Run Perspective

Burndown charts described in previous paragraphs are description of iteration. But does a nice Burndown chart indicate a great team? Maybe if your team indicates great progress for more than one iteration. Does the team believe in such success? I would be personally careful. We all know about changes coming every minute. Maybe the team provides conservative estimation for their safety.

Management usually takes care about the improvement of velocity, sprint by sprint. Please, do not expect that. Velocity is not an indicator of the team. Velocity is not a KPI by which you should measure your team. Velocity is just capacity planning tool. Nothing more, nothing less. Asking people to accomplish more story points in iterations will result in stories that have more story points estimated without real reasons. It could be name as "Story points inflation".