Shulou(Shulou.com)06/03 Report--

Most of the time, we feel like a day has passed without doing anything, but for leaders, it's best to get things done ahead of time, and the sooner the better. Smart managers know that "time" is a limiting factor that takes a lot of effort to control. Only when we have more data about time and work, can we better implement the plan and complete the project on time and within budget.

Burnout diagrams are tools used to reflect the data of such projects and are often used in agile software development, such as Scrum. It can present the remaining workload and available time, and express the meaning that can not be expressed by complicated words through visual diagrams.

First, what is the burnout map?

The burnout diagram can show the progress of the team in dealing with the user story, and it is a tool for visualizing the completion of the work. The burnout diagram can show the amount of work that still needs to be done in each iteration.

The horizontal axis of the burnout diagram shows the number of working days, and the vertical axis shows the remaining work, reflecting the progress since the start of the project. It allows each team member to see the current progress, and the team needs to update the burnout diagram regularly to maintain its accuracy.

At present, there are two forms of burnout diagrams, the Sprint burnout diagram is used to show the remaining workload in the iteration, and the product burnout diagram is used to describe the remaining workload of the entire project.

What are the common types of burnout diagrams?

CORNERSTONE divides the burnout diagram into seven cases, which are modified by individuals according to their understanding and actual situation:

Case1: perfect. Feature: a straight line. The figure is as follows:

This situation is basically impossible unless your team is all gods. If your team looks like this, you may have met a fake team: the burnout picture is pure fiction, and if there is a perfect picture, it is a coincidence.

Case2: beer belly. Features: arc-shaped, and the actual curve is always above the ideal line. The figure is as follows:

The reason for this is:

1. The estimation of prior demand is not accurate.

2. The team encounters obstacles and the ability of team members is limited.

3. The team has a strong ability of self-adjustment, can complete a lot of extra work, and the vision of not going home until the goal is achieved.

In this case, it should be noted that when we find this problem all the time, it means that we are in a high-risk state, and it is very likely that the goal of sprint can not be achieved. SM needs to predict the risk in advance and make adjustments, such as:

1. Is there any other optimization method that can realize the current demand?

2. One or more people get stuck on a problem and remove the obstacle

3. Can you negotiate with PO to reduce the content promised by the current sprint? if you can't finish it, then negotiate with PO, do the high priority, and put the rest on the next sprint.

Case3: big S type. Features: beer belly in the early stage, rapid decline in the later stage and below the straight line. The figure is as follows:

This situation shows that the team is adaptable and constantly adjusts the speed to achieve the goal. Of course, there is also a possibility that people see that the risk is relatively high now, and then work overtime (how painful to understand, who says Agile does not work overtime, it depends on who is doing it. ), no one goes home until the curve is lowered!

Case4: small S type. Features: wobble. I wobble... The figure is as follows:

This is a normal situation, the team is constantly adjusting their state, and finally achieved the goal. If your team's actual burnout diagram is similar, congratulations.

Case5:TBD . Features: there is no end point, there is some work left to be done. The figure is as follows:

Possible situation:

1. The leader oppresses and gives more work, and there are new needs every day.

2. The team has gone to gang up and play games, and few people do things.

3. SM has no risk estimation and processing ability.

4. The team can not arrange the work reasonably.

5. There is a big pit, and it is very big.

When you encounter this kind of problem, it is still necessary to make a risk prediction. I can't finish it until the next sprint, but don't extend the cycle of this sprint (for example, 2 weeks to 3 weeks). Once the rules are broken, the next time the team will no longer follow the Timebox (time box), there will be no inherent sense of rhythm.

Case6: open and hang. Features: straight down, always below the ideal curve. The figure is as follows:

Possible situation:

1. The demand is overestimated. In fact, there is not so much work to do. Members say no at the SP meeting, but they are still very honest in the actual work center.

2. Demand has been cut.

3. There are new motivators in the company, and programmers work hard and efficiently.

The most annoying thing about this situation is PO, which usually ya po people to get more tasks. Similarly, as a da za, SM should also encourage the team to move more bricks and get more money. Only in this way can we buy bags for girls.

SM should optimize the efficiency of the team and maintain a stable sense of rhythm.

Case7: God is in heaven. Feature: keep going up. The figure is as follows:

Instead of falling, the curve keeps rising, and the most likely scenario is that new demand is added to the current sprint every day. Of course, it is also possible that developers are too optimistic in evaluating their work, resulting in a growing workload, and the end result is that the current sprint must be terminated.

The above situation describes the burnout map types in most cases. What SM needs to do is to predict in advance and prevent risks, rather than waiting for the problem to be solved.

Third, how to interpret the burnout diagram

The burnout diagram has the following main points, it has an X axis, which represents the time of the project or iteration, and a Y axis, which represents the work that needs to be done in the project, and the remaining workload of the user story is also represented by that axis.

The picture shows the CORNERSTONE burnout diagram.

The project start point is at the highest point on the left side of the chart and occurs on the 0th day of the project or iteration. The project completion node is located on the far right, marking the last day of the project or iteration.

Planning curve

The planning curve in the burnout diagram is a straight line connecting the starting point and the end point. Because it represents the sum of all the estimated tasks that need to be completed, the end of the planning curve should pass through the X axis, indicating that there is no more work left. But since it is based on estimates, it is not always accurate.

Actual curve

There is also an actual curve in the burnout diagram that shows the actual remaining work in the project or iteration. At the starting point, the planned remaining workload is the same as the actual remaining workload, but as the project or iteration progresses, the actual remaining work curve will fluctuate above and below the planned work line. The actual remaining work line adds a new point every day until the project or iteration is completed to ensure that it is as accurate as possible.

If the actual work line is higher than the planned curve, it means that there is more work left than expected, in other words, that the project is behind schedule. However, if the actual curve is lower than the planned curve, it means that the remaining workload is less than expected and the project progress is faster than planned.

4. What are the benefits of burnout maps?

The most significant benefit of burnout maps is that they can provide up-to-date reports on project progress and update status, and provide a visual display of these important data, ensuring that everyone is on schedule.

In addition, showing the burnout diagram to everyone allows all team members to actively participate in the project and motivates them to deal with possible problems in advance. So the bigger and more visible the chart, the better. Burnout maps should be the visual focus of the office, which in turn leads to discussions about the project and schedule.

A concise burnout diagram is useful because it is the best tool for viewing the historical speed (Velocity) of the project. Velocity is an agile term that represents the sum of estimated effort related to user stories completed during an iteration.

The CORNERSTONE burnout diagram shows everything planned by the project manager and provides an assessment of the expected and actual status, which can help the project manager to analyze the project deviation at any time, adjust the project direction in time and avoid risks.

5. What are the limitations of the burnout diagram?

The burnout table cannot present all the information.

For example, it shows only the amount of user story work that has been completed and cannot predict any changes, such as estimating all the points of the to-do list (backlog) within the scope of work. Therefore, it is difficult to tell whether the change in the burnout diagram is caused by the completed backlog or by the increase or decrease of story points. Adding a special chart showing the total amount of backlog to the burnout diagram can solve this problem.

However, the burnout chart (shown in the down or up lines) does not show which products backlog has been completed. The burnout diagram shows the progress of the project, but it does not show whether the team is doing the right thing, nor can it tell whether the team is delivering the right product backlog.

Burnout diagrams depend on accurate estimates

Another problem with the burnout diagram is the ideal residual work line. Whether the actual work line is above or below the ideal work line depends on the accuracy of the estimation of the original time of the task. Therefore, if the team overestimates the time requirements, the actual progress of the project may seem normal or slightly ahead of schedule. But if you underestimate the time requirements, you seem to be behind schedule.

The problem can be solved by incorporating the efficiency factor into the burnout diagram. Therefore, higher accuracy can be achieved by recalculating efficiency factors after the first iteration of the project.

VI. historical review of burnout diagram

Combustion diagrams were developed from the Scrum community and were first used to manage software projects and other related work around 2000. Ken Schwaber describes the burnout diagram for the first time, so it is also considered to be the inventor of the burnout diagram. Ken Schwaber, who was working at Fidelity Investments at the time, created a burnout diagram to provide the Scrum team with a simple tool to help them chart the progress of the project.

By 2002, burnout maps were becoming more and more popular in the Scrum community. Since then, burnout diagrams have been used in areas other than scrum and have become a useful tool for managers to control the progress of projects.

CORNERSTONE provides professional agile development template tools, including task / requirements / test management, iterative planning, defect tracking, report statistics, team collaboration, WIKI, shared files and calendars and other functional modules, perfect match the entire agile development process, teams of less than 20 people can use for free, click to sign up for CORNERSTONE for free.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.