Four teams, four estimation units, one dashboard color, how do you handle this?

[Maria Reisinger _MetaFrazo_]

This pattern keeps coming back in larger organizations, and I'd like to know how the admins here handle it.

The example is not mine. I picked it up from a discussion on r/agile, where a commenter with 25 years in banking described the same pattern across five organizations.

Team A estimates in story points. Team B in hours. Team C in t-shirt sizes. Team D has a custom field called "effort" that nobody fills in. All four roll up into the same program dashboard, which turns them into one chart. When the bar is green the program is "on track." When it goes red, someone asks why it's behind.

The aggregation is arithmetically valid and semantically empty. The number underneath means four different things, and nothing in the interface signals that. The color ends up making the decision.

 

The obvious fix is to standardize: one scale, one workflow, mandatory fields, gates that can't be skipped. But you know how that goes. Teams add dummy transitions to get past a gate that doesn't fit, and a workflow built for a bank slowly suffocates a small product team. You trade unstructured mess for structured mess.

There is a quieter cost underneath. The day someone asks what a decision was actually based on, an approval that got skipped, a release that was signed off, the configuration only tells you what the process was supposed to be. What actually happened lives in the event history: who changed what, and when, for as long as your plan keeps it. If you can't read that back, a green bar in a screenshot is the only answer you have.

For what it's worth, the thing I've seen come closest to working isn't more rules, it's fewer, applied consistently. A small set of fields that must be filled before a ticket moves to Done, and teams left free otherwise. Not elegant, but it tends to survive contact with real teams.

A couple you can check on your own instance:

• For each aggregated value on your dashboard, which unit actually sits behind it, and do the feeding teams know?
• Can you reconstruct, without asking anyone, when a workflow was last changed and by whom, and how far back that still works? Company-managed workflows do expose a version history through the REST API, but only 60 days of it, and nothing from before 2025-10-30. Team-managed projects expose no definition endpoint at all.
• Which transitions exist only to let tickets past a gate?

And I'm genuinely curious how you handle it:

• Do you enforce one way to measure across teams, or accept the dashboard is directional and manage expectations instead?
• When someone later asks how a workflow reached its current state, and it is outside that window, can you reconstruct it, or is it effectively lost?

Would love to hear what works in your org.

(Disclosure: I'm a co-founder of a company that builds operational and compliance analytics for Jira, which is why this pattern is in front of me a lot. This post names no product and links nowhere.)