Tracking/Summary of Improvements (Kaizens) in Confluence

Question

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.

Bartek_ Vojtech · Answer

Use this https://www.easyagile.com

Jerry Ward_3t41w8 · Answer

We ended up creating a Kaizen issue type and will just track it that way.

James Bullock · Answer

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:

* Jira (or some other workflow tool) supporting complex, high-volume, high-precision workflows;
* Trello (or some other Kanban) supporting WIP summary dashboard;
* Confluence (or some other rich KMS) supporting the fact set / source of truth.

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.