Why capacity planning in Jira starts with cleanup

What the customer asked for

The customer came to us because they could not see across their Jira environment. Leadership wanted capacity planning, a central roadmap, and initiatives that rolled up across teams. Most of the conversation was about roll-ups and capacity.

That request is common, and it is reasonable. But it describes the result they wanted, not the problem in front of them. Planning tools can only report on data that means the same thing everywhere. Theirs did not.

What was really going on

Every team used Jira its own way. There was no shared way of working, so there was nothing consistent to roll up. The real work was cleanup and governance, and it had to come before any planning.

Done did not mean the same thing everywhere

Teams had built their own workflows, and many had gone deep on what each status should be. One team's done was another team's ready for review. When statuses carry different meanings, a roll-up across teams is just a sum of numbers that do not match.

Several fields meant the same thing

Over time, teams had created their own fields for the same idea. You could find many fields that all tracked roughly the same data under different names. You cannot report on a concept that lives in several places at once.

Spaces were not organized around teams

Spaces (what Jira used to call projects) had grown one request at a time. Some were team-managed, with configuration only that team could see and change. Work that belonged to one team was spread across several spaces, and some spaces mixed several teams.

Too many people could change configuration

Admin rights had spread widely. When many people can add fields, edit workflows, and create schemes, the environment drifts no matter how good the original design was.

How we found it

This did not take a long audit. The complaint itself told us most of the story. When a customer says they have no single view across their teams, the cause is almost always inconsistent configuration.

To confirm it, we took a sample of spaces and compared their fields, work item types, and workflows. A handful of spaces was enough to show how the problem had formed and how widely it had spread.

The fix

We treated this as a sequence. Planning came last on purpose.

1. Define the teams. We worked with the customer to agree on who the teams were and who worked together. Everything else hangs on that answer.
2. Make spaces team-centric. We consolidated spaces so each one matched a real team, and moved away from team-managed spaces so configuration was shared and controlled.
3. Simplify workflows. We cut statuses down to what a status should actually tell you: where a work item is. Nothing more.
4. Consolidate fields. Fields that meant the same thing became one field, so reports could use it everywhere.
5. Remove what nobody used. We cleaned out unused fields, schemes, and configuration so the environment is easy to administer later.
6. Reduce administrators. We pulled admin rights back to a small group that owns configuration going forward.
7. Set working practices. Teams agreed on basics such as estimating their work, so capacity numbers would mean something.
8. Build planning on top. Only then did it make sense to set up Plans for capacity, roll-ups, and cross-team initiatives.

Keep workflows simple, and put detail somewhere else

This is where most teams push back. They worry that a shorter workflow loses steps they care about. It usually doesn't. The detail still exists; it just lives in the right place. Components, fields, and releases can carry most of what people were trying to force into statuses. A simple workflow is easier to report on, easier to maintain, and harder for teams to drift away from.

The decisions they had to make

The technical cleanup was the easy part. The harder decisions were about people and habits.

• They had to agree on team boundaries and who worked with whom.
• They had to accept shared, standard workflows and fields instead of each team's version.
• They had to take admin rights away from people who were used to having them.
• They had to build internal champions who could explain why the new way was better.

That last point matters most. This is a cultural change. People need to hear, from someone they trust, that they are not losing anything valuable. Education did more to make the change stick than any configuration we built.

What changed

The cleanup itself made the strongest case for simplifying. Much of what we removed was not being used at all. That told everyone how much value it had been providing, and it made the argument for a simpler setup hard to dispute.

The standard held. Teams aligned on one way of working. Capacity planning and cross-team initiatives did not arrive overnight, and I would not promise that to anyone. What arrived right away was clarity: everyone could finally see how every team worked. That clarity gave the customer the confidence to take on the larger reporting goals.

Where this connects to identity and agents

Two parts of this work matter beyond reporting. The first is who can change configuration. Pulling admin rights back to a small, named group is an access decision, and it is what keeps a clean environment clean. The second is consistency. Agents that read or update work items need statuses and fields that mean the same thing in every space. An agent cannot reason about done if done has several definitions. The same cleanup that makes roll-ups possible makes automation safe to trust.