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

[zoltanersek]

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.

[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 

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 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!