In practice I've found a 2-3 sentence update for each project on what's been achieved for any given project on the team and what's happening next is more than sufficient. Bonus points for capturing the highlights and action items from the retro. You'll still get questions/kudos for progress, but its easier to discuss the root causes without reaching for the "process change" tool.
I always try to avoid to give such KPI toward management. They fall in love with it and then it leads to just KPI limbo... It can be faked, or manipulated to obfuscate reality...
Another funny story : Once our department head was really angry because we wanted to open our Jira board inside the company. :D He afraid of that others would see that not everything is awesome... And it will have negative consequences. Ok this fear is also strengthened by the clueless upper management who has no idea how sw dev is done...
In my experience enforcing complicated processes only improves the creativity how to avoid them... Don’t missunderstand me, I’m not against processes, but I believe in keep it simple and stupid.
It can, but it (almost always) isn't. Previous discussion:
By the time you're hiring a jira specialist and talking about workflows and restricted state transitions, something has probably gone very wrong though.
Also worth remembering, as we rail against this stuff - good people don't need to be encumbered by that much process to produce good things, especially in small groups. But not everyone is that good, and groups don't always stay small. Not that that means that adding process is always right, but it is another factor to keep in mind.