Wednesday, December 20, 2017

The Burn-Down Chart as a Fundamental Metric in Agile | Supreme Agile

תמונה קשורה
The Burndown chart is a fundamental metric in agile, the metric presents the team progress in completing the committed user stories and it provides a quick view of when we can expect to be done. The main parameters in this graph are the amount of work reaming (usual story points or days) and the time remaining until the end of the iteration.

The Burndown chart should consist of:
  • X-axis to provide information about the iteration working days
  • Y-axis to provide information about the remaining work
  • Ideal effort as a basic guideline for the effort need to be completed.
  • Real team progress of effort

The burn-down chart is the main tool of the team to provide viability about the state of the project because it can answer the main questions that asked during any project: 

Types of Burndown Charts

Sprint Burndown Chart

The Sprint Burndown chart is a visual measurement too, that provide a quick insight into the completed/remaining work per day for the current sprint.  Benefits:
  1. Provide a quick review of the team effort.
  2. Will allow the team stakeholders to take fast decisions based on the graph results (that will help to remove impediments that are affecting the progress).
  3. Provide daily feedback on the team progress.
  4. Provide transparency to the team performance.
  5. Help to determine if the team can accomplish the sprint goal.
  6. The main communication tool for customers and product owner. 

Release Burndown Chart

In scrum, the release is determined by the delivery of a product from development to the customer. A release Burndown chart helps the stakeholders to get a very good view of the release progress by determining the amount of the remaining work (X-Axis = No of sprints, Y-Axis – The remaining effort). 

How the Burndown chart is built?

The Committed Work (Y-Axis)

Prior to starting a sprint, the scrum team first selects a number of user stories they want to accomplish, the process of analyzing, Prioritizing and Estimate the PBI's is done in a dedicated meeting called "The Planning Meeting" that is done prior to the start of each sprint. To get the work estimations, we need to combine all estimations of the PBi’s committed by the team (Y-Axis).

The Iteration working days (X-Axis)

The X-axis represents a unit of time (2-4 weeks) represented by days, by following this axis, we can determine the amount of work completed for a specific time. 

What is the Total Work Estimate?

The total work estimate is the sum of the efforts (Hours) of all the user stories which the team is committed to.

What is the Remaining Work Effort?

This question can explain why this graph gets its name (“Effort Burndown Chart”), by looking at the graph, we can get an instant look at the effort made by the team per day.

What is the Amount of Working Days?

The question can easily be answered by just looking at the graph that shows the total days of commitment of workdays (Sprint Duration).

How Much Work Done by Now?

The graph also present the amount of work that the team accomplished through a period of time (This data can be also used to predict the iteration future progress).

What is the team velocity?

The graph can provide an instant look at the current team velocity, the calculation is made based on the work done for a given period of time.

Can the Team Add More Stories to the Iteration?

If the PO decides to add more work to the iteration/project, the team can instantly review the burn-down chart and see the impact that the new demands on the current delivery date.

Burndown Chart Team Scenarios

Although the Burndown chart contains only two lines, there is a major importance to understand the different situations they describe. These situations are probably the most common (Depends on the quality and experience of the team):

The Role Model team

This team characterized by two major qualities:
  1. Has the relevant experience (Technology/Agile).
  2. The team is familiar with the importance of agile commitments.
  3. The team can adapt interruptions that may arise during the iteration.
  4. The team embraces the retrospective meeting to achieve continues improvement per iteration.

Although the team started with some gaps, they manage to resolve all issues and complete the iteration on time. In addition, the team will use the retrospective meeting to resolve all issues appeared in the last iteration to become better in the next iteration. 

The Ideal Team

The Ideal team characterized by three major qualities:
  1. The team is able to organize itself.
  2. They know their velocity and boundaries, and therefore will not commit to a number of user stories that will lead to “Over-commitment”.
  3. They have the ability to estimate capacity correctly to remove the unnecessary loss of working days.

The Burndown chart of this team will indicate that the team has finished all commitments on time. 

The Average Team

The average team is a team that is able to complete their commitment and iteration goals. Based on the represented graph, we can see that the team is able to adapt to the delay they had during the iteration and work harder to complete the remaining work.

This graph is more common for experienced agile teams for the following reasons:
  • They don’t panic once they have an unexpected delay.
  • They know how to adjust to the new challenges and hard work that they will need to perform to meet the iteration goals.
  • The team knows how to prioritize the iteration stories (Low prioritized stories return to the product backlog).

They have good communication skills that allow them to take decisions immediately as they see the delay from the beginning of the iteration. 

The Team that Can Do Much More 

There is a good reason way team commitments are so crucial in agile software development, the main reason is that once the team is committed to delivering a set of stories, the expectation from the other stakeholders is that the team will deliver what they committed to, simple as that.

The Burndown chart can reflect unaccomplished commitments in a very easy and graphical way, but in addition, it can tell us when the team fails to adopt the iteration scope to a work level that will allow them to meet the top prioritized stories.

It is very important for the team to take active corrections once they discover that they cannot handle the work capacity (you will see it once there are a few days of slower progress), the most common corrections are:
  1. Move user stories to the product backlog (for re-estimate/Prioritize).
  2. Move user stories to the next iteration (If the priority remains high).
  3. Split stories to smaller units.
  4. Reduce the next iteration capacity (There is no reason to set the same capacity if the team cannot handle the work effort).

The Nonfunctional Team 

The graph of such team will present a scenario that represents a catastrophic picture about the team performance that may arise from many reasons:
  1. The team is not committed to the process.
  2. The team is not coached enough to track progress on a daily basis.
  3. The product owner does not care about the work done by the team and therefore does not ask any questions.
  4. The scrum master fails to enforce the agile spirit and practices throughout the iteration.
  5. The team does not update their daily progress on purpose.
  6. The team does not do an effective retrospective meeting that mitigates wrong behavior. 

The Team that Ignoring Work Estimations

In this scenario, the iteration Burndown chart will indicate that user stories (and the associated tasks) were not estimated during the iteration-planning meeting and added to the iteration without time estimations.

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

Team With Over Commitments

This graph represents a team that took a scope of work that is too big for them to handle, as a result the team fails to meet the iteration commitments.

The Team that Overestimated the Scope of Work

This graph represents a team that finishes its work earlier than they expected but didn’t take corrective actions, such as work on additional stories from the product backlog (Although they had the capacity to handle it).

The Team that is Not committed Enough

Although the team will succeed to finish their commitments and meet the iteration goal, the Burndown chart display a problem in the team behavior, this problem is related to one of the following reasons:
  1. The team is less committed and took a break in the middle of the sprint (Although they have more capacity to extend the work effort).
  2. The team committed to fewer user stories, although the team velocity allows them to add more work.

No comments:

Post a Comment

My Presentations