One of the daily follow-up series of agile development: burnout diagram (on)

This is the first article in the routine follow-up series of agile development (topic directory ).

This series will cover burndown charts, storyboards, and each Hitachi meeting. It will describe before the planning and review meetings, the agile development team internally produces various activities with product managers and project managers.

Some content in daily follow-up, such as the team work model, prediction meeting, and user story follow-up, are described in the previous series of loose programming, team management, user stories, and product management.

Before this series, there should also be an agile plan series that describes the details of agile development from version planning to estimated plans and will be completed in the future, currently, you can refer to the 2.29 release of the agile development manual, which corresponds to five pages.

Burnout Diagram

The burdown chart is also called a burning chart. It is a rare agile measurement. When someone asks "Is there a measurement in agility?", the first reaction is it.

The full name of the burnout diagram should be the "Burnout diagram of the total remaining time", which is the sum of the remaining time of all stories (or split tasks, hereinafter referred to as stories) in this iteration, A chart that decreases daily as the date changes.

In the figure, 460 on the left is the first day of iteration. The total unfinished time of all stories is 460 days. On the rightmost side, the remaining time of all stories is 0 in 17th days, that is, all the stories have been completed.

Why does the sum decrease? Because each member has to report one thing every day: there are still several days left for the story being done. If there are three days left for yesterday and two days left for today, therefore, it contributes a one-day progress to the combustion chart.

Because it may appear that "three days left yesterday, after one day of work, I thought it would be only two days left, and the result may be three days (or even five days !)" In this case, the burn-out chart often has some ups and downs.

"Fingerprint" of the burned-out chart"

Although there are some ups and downs in the burned-out diagram, it is still a perfect burned-out diagram. In fact, the process of completing iterations by each team varies greatly. common situations include:

Bulge first and then drop

The reason is that the Plan often misses some things, so not only does it not burn out after the project starts, but also discovers many new tasks.

First perfect combustion, then suddenly stop burning

In a very common situation, if the task is too rough, for example, up to 10 days, it is easy to "do 1 day, 9 days left; do 1 day, 8 days left; ...... 2 ~ In the past three days, it seems that I am not sure ".

First, it will burn slowly, and then a bunch of incomplete tasks will be delayed until the next iteration.

I have mentioned the Moscow method of agile development before. Some stories are secondary "can not be done", so this kind of combustion chart is also common. However, some teams often do not use the Moscow method, it is just passive discovery that some stories are not completed.

......

To improve these imperfections, some teams have set some metrics to improve the burn-out chart results, for example, "Number of times of rolling-out on time during iteration" and "proportion of remaining stories to total stories "......

In fact, you don't have to worry about the imperfection of the burn-out chart. In the agile "no-stick", we once mentioned that these methods are not our purpose, but just an intermediate tool, therefore, to achieve our ultimate goal, these tools and methods can be flexible and flexible, instead of pursuing the perfection of tools and measurement data.

But what is the ultimate goal of iteration? What "flexibility" can be applied in the burn-out diagram? And wait for the next decomposition.