Scrum Kaizen Through Charts
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.
関連記事 | Related Posts
Which Agile Milestone Are We at Now?
Don't Just Crush Bugs, Prevent Them: Quality Improvement Initiatives
2024 Kick Off! : Journey to Our First Company-Wide Offline Gathering
Exploring the Ability to be a Self-Reliant Person
Transforming Development Methodologies: Our Journey from Waterfall to Agile in Crafting the Prism Japan App
A Look Back To This Year And Into 2024
We are hiring!
【PjM】プロジェクト推進G/東京
プロジェクト推進グループについてプロジェクト推進グループでは、TOYOTAのクルマのサブスクリプションサービスである『 KINTO ONE 』をはじめ、国内向けサービスのプロジェクト立ち上げから運用保守に至るまでの運営管理を行っています。
【コーポレートエンジニア】コーポレートITG/東京・名古屋・大阪
コーポレートITグループについてコーポレートITグループは生活基盤インフラ(電気・水)をイメージして、スタッフから頼られる必然の存在を目指し、エンジニアリング以外に時間を取られない環境整備を仕組みで実現していきます。