Study of Burndown Chart

Burndown Chart functions and elements

Burndown chart (burn down chart) is a visual representation of the work that needs to be done before the project is completed. The Burndown chart has a y-axis (work) and x-axis (time). Ideally, the chart is a downward curve, with the remaining work completed, "Burnt" to 0. Burndown charts provide a public view of the work progress of project team members and business owners. This word is often used for agile programming.

Burndown charts are used to observe the relationship between the actual work done during the project and the remaining time. The vertical axis of the Burndown chart can be the remaining task for the entire project, or it can be the whole of the individual's remaining tasks.

Meaning of using Burndown chart

Burndown chart shows a new management work report that shows managers and stakeholders the current backlog and overall progress, and management and stakeholders can easily understand real-time progress and details through Burndown charts, and management will be able to grasp the progress of the product and make the right decisions in real time. and anticipate risks and adjust the plan at any time.

Traditional project reports are generally fixed, systematic, show managers the progress of the project, the percentage of completion, and the problems that need to be addressed and remedied, while in fact in the development process, there will be a constant need to add in, this traditional project report can not respond to this demand, The result is that the project's failure is often attributed to the increase and change in demand and the inability of management to make the right decision.

How to respond to changes and make relatively correct decisions for management and stakeholders requires project performers to present project details to management and stakeholders, which must be visually, credibly, measurable, and fully present the details of the execution of the project, and Burndown charts can solve such problems

What kind of Burndown chart can achieve the effect

At the beginning of the article, we have explained the Burndown chart, and give the expression method, unfortunately we are not looking for a well-packaged chart, but to find a way to solve problems in the project, Burndown Chart can help us solve the problem, it is a method, must achieve some effect, if the Gantt Chart can also help us, We will also use it. So we care about the benefits and outcomes that it produces.

Then we should think about the Burndown chart first.

What kind of effect should it have?

Or how to deal with tradition.

Problems that cannot be solved in the project?

The previous reports of traditional projects tend to be relatively late-pure, not timely adjustment, and once the demand changes, the probability of project failure will increase, often managers decision-making time can not be remedied, and managers are difficult to see the effect of his investment. So we can ask the Burndown chart to have the following effects:

1):

Visibility, visual display of project progress and backlog completion

2):

Have risk estimates to remind management and stakeholders of the current situation, and where is the bottleneck?

3):

Measurable, intuitive display of the time required for the current project

Example Analysis of Burndown chart

This project uses the Burndown chart (sprint burn-down Chart) to monitor and analyze the progress of the iteration, and each Burndown chart is automatically drawn from Excel based on the daily update data of the sprint backlog.

Burndown Chart Horizontal: Duration.

Burndown Chart ordinate: Total commitment work for work tasks within a sprint.

Planning curve: A progression curve assuming that the member's working productivity is constant.

Actual curve: Actual progress curve.

Spring_1 Analysis:

1. Team members start the first sprint, the breakdown of the work task is not proficient, to their own work productivity is unclear. The result is a further refinement of the July 13 work task, resulting in a higher actual curve than the planned curve.

2. Although, from July 12 to July 18, the actual curve is higher than the planned curve, the trend of the actual curve coincides with the plan curve, indicating that the production rate of the team members is constant.

3. On July 19, the actual curve fell back, and the development group submitted the iteration version to the test as a result of iterative system testing.

4. The last working hours are still present, and there are problems in characterizing members ' hours.

5. At this sprint review meeting, the team members agreed that "development and testing are closely integrated and release and testing can be released in a timely manner."

Spring_2 Analysis:

1. From July 25 to July 29, the trend is generally normal.

2. On July 30, the actual curve rose, the analysis found that there is still insufficient granularity of task decomposition, the member found that the task of the more work required to do more. The deep-seated reason is that when the task is decomposed at the beginning, due to the demand, design and other reasons, the task time estimate and the actual existence of large deviations.

3. At this sprint review meeting, the team members agreed that "team work time is more accurate", but "the granularity of the task needs to be appropriate, the objectives clear, and there is no cross-iteration." Task decomposition needs to be improved "

Spring_3 Analysis:

1. The overall trend is normal, but the real reason is that the external influx of new tasks, the impact of the time box, in order to ensure the release of the original planning of some tasks have been shelved.

2. At this sprint review meeting, the team members considered that "the number of tasks within the project has been increased" and that "the task bugs in the sprint need to be modified; The bugs outside the sprint need to be evaluated, consider establishing new tasks"; Temporary tasks outside the project often join sprint ”。

Spring_4 Analysis:

1.8 months 24th, due to PB inside the user story items received changes in demand, resulting in a significant increase in estimated work hours.

2. At this sprint review meeting, the team members agreed that "The requirements description needs to be clearly in place, the details of the requirements should be communicated in a timely manner," "The PB itself is not clear enough to be detailed before the sprint, and each member of the team will participate in the analysis and refinement of the requirements, time and sprint parallel The team members should be consistent with the clear results of the requirements.

Several burndown charts are just a few of the sprint Burndown charts from the actual Agile development project, and the following agile practice records

Study of Burndown Chart