nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

At what team size did you feel the need to formalize your Jira workflows?

zoltanersek _outpostlabs_dev_

I've been wondering whether there's a tipping point where "every team does Jira a little differently" stops being sustainable.

I'm at a Series D company with around 200 engineers (600+ people overall), and while teams have a lot of autonomy, it also means workflows, issue types, custom fields, and boards can vary quite a bit. Sometimes that's great because teams optimize for themselves. Other times it makes cross-team reporting, onboarding, and collaboration more difficult.

For those who've been through this as your organization grew:

At what point did you start standardizing Jira?
What did you standardize first?
Is there anything you deliberately left up to individual teams?

I'm especially interested in hearing from people who've found a balance between consistency and giving teams the flexibility they need.

Comments

Dave LIAO

Love this post!

One takeaway I learned from being part of Jira governance is, be as clear as you can on what you're standardizing on (and why) and what you're NOT standardizing on.

There are many factors to consider - what are the most important and urgent goals your organization has? Then consider what you need to change - or maintain - in your Jira to meet those goals.

For example, if reporting cycle time is important, it's ideal to start harmonizing workflows across teams. Teams should use a shared set of statuses and know what they mean.

On timing, it's never too early to standardize. That's proper tool governance, and this standardization helps ensure your users are using your tools properly.

Viswanathan Ramachandran

hi @zoltanersek _outpostlabs_dev_

This is great question and wonderful opportunity for others to share their wisdom.

We started standardising during our migration from Jira Server to Data Center, it was the ideal opportunity to reset rather than carry technical debt forward.

We standardised the core platform: workflows, issue types, schemes, permissions, and governance around a common SDLC. We also cleaned up unused projects, custom fields, and configurations to reduce complexity and improve reporting.

Where teams needed flexibility, we left board configurations, dashboards, team-specific fields (where justified), and backlog management to them. The principle was simple: standardise what affects everyone; allow flexibility where it only affects the team.

Key takeaway: Build consistency into the platform, not the team’s way of working. Strong governance and sensible guardrails improve collaboration and reporting without taking away team autonomy.

Davit Mkrtchyan - Be On Time

Hi @zoltanersek _outpostlabs_dev_ Zoltan -

Dave and Viswanathan gave some excellent advice on the administrative side. Getting your core platform and SDLC aligned is definitely the right first step to stop the technical debt from snowballing.

I would like to add one perspective from the PMO side that often gets overlooked during standardization.

At your scale (200+ engineers), you will find that even perfectly harmonized workflows cannot solve the "Resource Collision" problem. You can have every team using the exact same statuses and issue types, but if three different teams are all relying on the same two DevOps experts or a single Lead Architect, your reporting will still look Green while your delivery is actually at risk.

The tipping point for me was when I realized that standardizing "how we track work" is not the same as standardizing "how we manage capacity."

If I could suggest one additional focus for your governance: look at how you visualize the Supply (your team's actual capacity) versus the Demand (the work in those standardized workflows).

Consistency in workflows is great for reporting, but consistency in resource visibility is what actually makes cross-team collaboration sustainable. It moves the conversation from "Why is this ticket still in In Progress?" to "Do we actually have the bandwidth to commit to this in Q3?".

Hope this adds a useful dimension to your planning!

zoltanersek _outpostlabs_dev_

Thanks, Dave! I like the idea of being explicit about what you're not standardizing as much as what you are.

Out of curiosity, have you found any areas that teams almost always want to customize, but that are actually worth keeping standardized in the long run?

zoltanersek _outpostlabs_dev_

I really like the principle of "standardize what affects everyone; allow flexibility where it only affects the team." That's a nice way to frame it.

Looking back, was there anything you standardized during the migration that, in hindsight, you'd leave to individual teams instead?

zoltanersek _outpostlabs_dev_

How have you seen organizations make capacity visible in practice? Is that something you've managed directly in Jira, or with separate planning tools?

Davit Mkrtchyan - Be On Time

Hi Zoltan -

In practice I have seen three patterns work, depending on maturity:

1. Jira as system of record plus a weekly commitment view (people x projects x hours) reviewed before planning.
2. Premium Plans when the org already has it and the pain is mostly within one portfolio.
3. A dedicated resource layer when collisions happen across shared specialists and multiple projects.

The common mistake is trying to infer capacity from In Progress counts alone. That tells you activity, not commitment.

At 200 engineers I would start lightweight: one shared view reviewed weekly, even if it is a simple grid at first. What matters is making overload visible before dates are promised.

Viswanathan Ramachandran

During the migration, nothing can be done. Because we used project configurator or Configuration manager which simply migrates from source to the target. The work was done either before or after the migration, depending on the project team request and requirements. it was phase by phase work.

For example:

before migration we agreed to migrate only open issues or last 2 years data for larger projects. Configuration manager does this.
after migration, we agreed to standardize their schemes to new SDLC scheme which was already setup in ours, then followed by archive old issues, data mapping, removing duplicate and so on..

For standardization, while technical work was more involved and doable.. engaging stakeholders, senior executives was heavily needed. Why we are doing this?
It’s advantages, benefits, features, creating architecture diagrams, documentation and discussions.

zoltanersek _outpostlabs_dev_

Thank you for your advice

zoltanersek _outpostlabs_dev_

Thank you @Viswanathan Ramachandran migrations can be very difficult sometimes

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

startup

process

workflows