Introduction

Hi! Thank you for your interest in my article! I am Yutaro Mikami, an engineer in the Project Development Division at KINTO Technologies. I joined the company in September this year and usually work as a front-end engineer on the development of KINTO FACTORY.

In this article, I will write about my experience and efforts since joining KINTO Technologies, focusing on the theme of "Agile."

Topic

As indicated by the title, I will talk about the initiatives we have undertaken to ensure accurate progress management in our team's Agile development, where our burndown chart shows that the actual work line is consistently above the ideal work line.(Good!👍)

Main Body

What Progress Management Should Be

Burndown charts provide a quick overview of the decreasing remaining workload, offering the following effects and benefits:

• Reporting progress to stakeholders
  
• Maintaining visual motivation for developers
  
• Early detection of task stoppers
  
• Promoting team cooperation and collaboration
  

Definition of Current Issues

With the above in mind, I will use my team's burndown charts for a sprint and summarize the issues I've identified.

Burndown chart before Kaizen (improvement)

As the work progresses, the graph goes down naturally, but the size of the gap between the graph rising irregularly and the ideal line at the end is noticeable.

Conclusion

Reporting progress to stakeholders

The report becomes unreliable because the team is unsure whether the rise in the graph is intended or not.

Maintaining visual motivation for developers

There is no downward trend in the graph, making it difficult to maintain motivation due to a lack of successful experience.

Early detection of task stoppers

Since we report progress on a daily basis, the team is aware that the task progress is falling behind. However, spotting task stoppers from the graph proves challenging, making it difficult to see the task progress is stagnating.

Promoting team cooperation and collaboration

There is adequate communication on a daily basis, but few cases of cooperation and collaboration through charts.

Kaizen Goals

A goal is not the end of the process, but for the sake of clarity, I used the word "goals" to describe what a team should aim for. The defined goals in this article are as follows:

• Be able to understand and control the progress of tasks through charts
• Be able to recognize the reasons for the rise while allowing the graph to rise as a team
• A sense of accomplishment through charts should be felt by each developer
• Be able to promote cooperation and collaboration throughout the team

After starting Kaizen

We are still in the process of Kaizen, but the chart is currently on an improving trend.

Latest burndown chart

What We Did Step 1: "Cultivating Awareness" Kaizen

Stop the approach of simply stacking tasks into the sprint.
This was the only specific action, but I think it was very effective.

By having this awareness within the entire team, we have successfully reduced the gap between the ideal line at the end of the sprint. In addition, the accuracy of velocity has improved, with the expectation of further enhancements to estimate precision.

What We Did Step 2: "Planning" Kaizen

Set up a "place to store tickets in the next sprint"

The breakdown of additional tickets to be stacked during the sprint includes two main categories:

• Forgotten tickets during planning
• Tickets added during the sprint

The tickets added during the sprint have several factors, and as it was difficult to improve in the short term, we first took action to prevent them from being left in the sprint.

We created a "task placement tickets to be stacked in the next sprint" to the backlog and started to discussions on the tasks listed above (red frame in the image) during the planning process. This led to the realization of the following effects.

Prevention of forgetting to stack

By adding action of moving tasks to the top of the backlog before planning eliminates forgetting to stack.

Improvement of task comprehension

The breakdown time per ticket has improved each member's understanding of the task.

Stack the appropriate number of tasks into the sprint

This is also linked to the Kaizen of Awareness, providing the opportunity to select the tasks to be stacked, rather than just stacking them anyway, allowing the appropriate number of tasks to be added in a sprint.

What We Did Step 3: "Kaizen Meetings"

In addition to the retrospective, time was set aside for members to discuss issues and improvements in our daily Scrum activities. Discussing issues to be addressed in the short to long term and deciding on next actions raised the team's awareness.

Results

Reporting progress to stakeholders

The report becomes unreliable because the team is unsure whether the rise in the graph is intended or not.

Improvements in graph accuracy and reliability have made it possible to report accurate progress.

Maintaining visual motivation for developers

There is no downward trend in the graph, making it difficult to maintain motivation due to a lack of successful experience.

There is a clear downward trend and successes have been achieved.
Actions on tickets added during the sprint are a future challenge.

Early detection of task stoppers

Since we report progress on a daily basis, the team is aware that the task progress is falling behind. However, spotting task stoppers from the graph proves challenging, making it difficult to see the task progress is stagnating.

Continue to report progress on a daily basis. I get the impression that the stoppers are ready to be seen from the graph.

Promoting team cooperation and collaboration

There is adequate communication on a daily basis, but few cases of cooperation and collaboration through charts.

There have been no cases of cooperation and collaboration through charts yet, but I feel that we have been able to build a system that allows cooperation and collaboration, because we can now better understand who is working on which tasks than before.

Conclusion

So this will conclude my article about conducting Scrum Kaizen as we analyzed our burndown charts. Thank you for reading till the end.

I have once again realized that iterating Kaizen is necessary not only for products but also for teams and processes to continue Scrum as a team. Objective improvements using reports and charts that are based on data makes it easy to identify issues, and visible improvements help maintain motivation.

I hope this helps your team's Kaizen as well!

Lastly, KINTO FACTORY, where I belong, is looking for people to join us! If you are interested, feel free to check out the job openings below.