You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Fundamental to Scrum is continuous improvement. Improvements, or Kaizen are generally identified in the sprint retrospective and hopefully implemented in subsequent sprints.
However how would one track these over time in more of a summary style? I know you could review the notes from each retro meeting, but that would be cumbersome.
I've started creating items in Jira for these improvements with the label Kaizen, but now I need a way to pull those into some kind of dashboard in confluence that would provide some kind of visual summary with the details listed out below.
Anyone with experience in this area I would love to hear what you are doing.
Nice work.
Tracking Process / Practice Changes: I've always had a "process errors" category in issue systems I manage, provisioning process / practice changes that trace to multiple shipped issues. The 14th time you have to scramble because your deployed bundle missed that one thing, maybe automate your push from a manifest, baselined and under change control. (Yes, the basic benefits of the current hotness "DevOps" have been known for approximately ever.)
Right Tool for the Right Job: I'm not as sure about a "progress" dashboard in Confluence. I generally think of the tools roughly as:
Improvement Dashboard and Results: If how you do things is in your KMS, an improvement dashboard is a natural page to make, with a backlog of candidate improvements, some WIP, and an inventory of improvements you've made. With stack-level integration between Jira and Confluence, "how" changes in the one can link to relevant issues in the other.
There's some additional rationale for each of those choices, and in practice they work. Really it's an info system design problem, designing the info system for wrangling creating your info systems. Approached that way, you get tend to get designs that work better.