The color decides, not the number

A thread in r/agile asked why Jira setups turn into a mess at scale. Forty-three replies later, the most useful answer was not about Jira at all. It was about what happens when four teams measure four different things and one dashboard turns them into a single number.

The pattern

A practitioner with 25 years in banking described the same situation across five organizations. Team A estimates in story points. Team B in hours. Team C in t-shirt sizes. Team D does not estimate at all but has a custom field called "effort" that nobody fills in.

All four report into the same program dashboard. The dashboard aggregates these values into one chart. Leadership reads the chart, and when the bar is green the program is on track. When it turns red, someone asks why the program is behind.

The number carries no shared meaning. The color drives the decision.

Anyone who has sat in a steering committee will recognize this. The problem is not that people are careless. The problem is that the aggregation is arithmetically valid and semantically empty, and nothing in the interface signals the difference.

Why configuration does not fix it

The obvious response is to standardize. One estimation scale, one workflow, mandatory fields, gates that cannot be skipped.

The same thread pushed back on this, and the objection is worth taking seriously. Enforcing key steps through workflow restrictions produces a system people work around rather than work with. Teams create dummy transitions to move a ticket past a gate that does not apply to their situation. One reply summed the result up as structured garbage instead of unstructured garbage, which is a fair summary of many governance programs.

There is a second problem specific to regulated environments. A workflow designed for a bank will suffocate a small product team, and the same organization often contains both. Standardization that ignores this either gets diluted until it means nothing, or gets circumvented in ways nobody records.

The setup that reportedly did work at scale used a lighter rule. Teams configure their boards as they like, but every ticket needs three fields filled before it can move to done. Which three fields depended on the organization. Minimum viable governance, everything else optional.

What this means for evidence

Here is where it matters for anyone who has to answer to an auditor or a regulator.

Configuration describes intent. It tells you what the process was supposed to be. It does not tell you what happened. A workflow with a mandatory approval gate looks identical in the configuration view whether the gate was respected, bypassed through a dummy transition, or reconfigured last March by an administrator who has since left.

The event history is the other half. Every status change, every field update, every permission adjustment leaves a record with a timestamp and an actor. That record is deterministic. It does not depend on how a team defines a story point, and it does not need a shared estimation scale to be comparable across teams. A transition happened at a specific moment or it did not. The one thing to check before relying on it is how far back your plan keeps it, because that horizon is usually earlier than people assume.

This is the distinction between a dashboard and a history. A dashboard shows a state. A history shows how the state came to be.

When a reviewer asks what the March release approval was based on, a green bar in a screenshot is not an answer. The sequence of transitions, who performed them, and when, is closer to one.

The questions worth asking

None of this proves that anything went wrong in any given organization. That is the point. Evidence lets you ask precise questions instead of defending a color.

• Which unit sits behind each aggregated value on your program dashboard, and do the teams feeding it know?

• Can you reconstruct, without asking anyone, when a workflow was last changed and by whom, and how far back that answer still works? Recent changes are retrievable. Older ones stop being retrievable at a date most people have never looked up.

• Which transitions in your instance exist only to let tickets past a gate?

If those questions are uncomfortable, that discomfort is information. It usually means the configuration and the reality have drifted apart, and that nobody is currently in a position to say by how much.

A closing note

The r/agile thread reached a conclusion that deserves repeating, and it is not about the tool. Configuration divergence starts small enough to ignore and compounds until it is too large to unpick. That happens in anything that lets teams configure their own process, and it is the price of letting them, which is usually the right call. Every team configures in a way that makes local sense, and nobody is responsible for global coherence.

You cannot solve that by adding rules. You can solve part of it by being able to see what actually happened, across teams, without asking each of them to agree on what a story point means first.

The color on the dashboard will keep driving decisions. The history is what you bring when someone asks whether those decisions were sound.