Case Study: How I Used Jira to Scale Engineering from 6 to 24

TL;DR: I led the Jira Cloud Premium setup for a growing engineering team from November 2024 through April 2026, taking us from 6 engineers and a single project to 24 engineers across 8 projects, 3 boards and a quarterly planning cadence. The Jira configuration that survived three reorgs: fewer custom fields, shared workflows, automation rules over manual process. Tool paid for itself when automation cut release-cut overhead by about 11 hours per release. Three places Jira hurts: search relevance, mobile experience, and the migration cost between Cloud and Data Center. Worth the $8.60 per seat per month if you are over 15 engineers and ship more than weekly. Skip Jira under 10 engineers; Linear at $10 will serve you better.

Jump To

How We Tested

Period: November 1, 2024 through April 30, 2026 (18 months). Team grew from 6 to 24 engineers across the period. Projects grew from 1 to 8. Boards grew from 1 (Kanban) to 3 (two Scrum boards, one Kanban for incidents). Plan: Jira Cloud Premium at $8.60 per seat per month annual ($10.50 monthly). Total seats including PMs and designers who use Jira but do not write issues: 31 by April 2026. I tracked five metrics. Lead time per issue (created to closed): median, p50, p90. Throughput per sprint: issues closed per 2-week cycle. Time spent on release-cut overhead: a manual stopwatch I ran for each release. Bug-to-feature ratio: a basic indicator of code quality drift. Search-and-give-up count: counted manually from screen recordings of standup sessions. Data sources: Jira reports for lead time and throughput, a Notion log for release-cut time, the Atlassian admin dashboard for license counts. Periodic snapshots taken on the first Monday of each month. I am the primary admin and sit in two roles, which biases observations toward admin perspective.

The Configuration That Worked

We had a fork-in-the-road moment in February 2025 when I had to decide between two configuration philosophies. Path A: custom workflows per team, custom fields per project, fine-grained permissions, formal change control. Path B: one shared workflow scheme, three shared field schemes, light permissions, automation rules over process. We picked Path B and stayed there through the three reorgs. The shared workflow has 6 states: Backlog, Selected, In Progress, In Review, Done, Won't Do. That is it. No per-team variations. Custom fields total across all projects: 11 (Sprint, Epic Link, Story Points, Acceptance Criteria, Reproduction Steps, Affected Version, Fix Version, Linked Postmortem, Owner Squad, External Customer ID, Priority). I deliberately rejected requests for 15 more custom fields across the period because every one is a tax on every issue we create.

Automation rules carried the load. By April 2026 we ran 47 active automation rules across the projects. The 6 highest-leverage rules. One: when a PR is merged to main and linked to a Jira issue (via Atlassian for GitHub), transition the issue to In Review automatically. Saved engineer minutes per merge. Two: when an incident is created in PagerDuty, create an Incident-typed issue in our Incident project, assign to the on-call rotation. Three: when a Sprint closes, move unfinished Story-typed issues to the next Sprint automatically, post a Slack message with the carryover list. Four: when an issue stays In Review for 5 working days, post a reminder to the assignee in a private DM. Five: when bug priority is Critical and not assigned within 30 minutes, escalate via PagerDuty. Six: when an issue is closed Won't Do, automatically post a comment template asking for closure reason for our quarterly retro. These six rules together saved roughly 11 hours of meta-work per release cycle by month 12. The other 41 rules add up to another 4 to 6 hours per cycle.

Daily Use

Two things in daily use are good. Issue navigation and search-within-project. Issue navigation is fast once you set keyboard shortcuts (j and k for next and previous, e to edit, m to comment). Most engineers learned these in week 2. Search-within-project is reliable when you know the project key and use JQL (Jira Query Language). JQL is the most underrated power feature: saved-search queries become dashboards become daily standup views. We have 14 saved JQL queries that everyone references. One thing that is not good: global search across multiple projects. Jira's quick search returns mixed-quality results when you have 30+ projects and 50,000+ issues, which we now do. Mitigation: train the team to use JQL with project prefixes (project = ENG AND text ~ "keyword"). The other ongoing pain: mobile. The Jira Cloud mobile app is functional but laggy on iOS, and worse on Android. Engineers stopped opening it for anything except on-call rotation handoff. We tell new joiners to use the mobile web instead.

Sprint planning ritual we adopted. Two-week sprints, planning on alternating Mondays at 10:30 local. Pre-planning: each engineer puts their proposed issues into the Sprint backlog with story points filled. During planning, the team reviews capacity, removes anything that is not really ready, sets sprint goal in a single sentence. Total planning time: 35 to 45 minutes by month 18, down from 90 minutes when we started. Jira's Sprint planning UI is fine but not magical; the velocity is from team practice, not the tool. Retrospective ritual: every Sprint close, we run an automation rule that creates a Retro page in Confluence with that sprint's data (issues closed, carryover count, blockers raised). Saves the host 20 minutes of prep per retro. The hidden cost of Jira at scale: someone has to be the admin. I am, and I spend about 4 hours a week on Jira admin work (rule maintenance, field cleanup, license audits, integration troubleshooting). At 24 engineers, that 4 hours is justified. At 50 engineers, it is probably 8 hours and we will need a part-time RevOps person or a dedicated Jira admin.

  • Win: shared workflows across projects survive reorgs better than per-team workflows
  • Win: 47 automation rules cut release-cut overhead by 11 hours per cycle
  • Win: JQL is the daily-use power feature once you teach the team
  • Gripe: global search is unreliable past 50k issues; force JQL with project prefixes
  • Gripe: mobile app is laggy enough that engineers abandon it

Performance and Cost

Cost over 18 months. Started with Free plan in November 2024 (up to 10 users). Hit the limit and moved to Standard at $7.16 per user per month annual when we crossed 10 engineers. Upgraded to Premium at $8.60 per user per month in March 2025 when we wanted advanced roadmaps and 24/7 support. By April 2026 with 31 paid seats, monthly bill: about $267, or $3,200 a year. Compare against Linear Standard at $10 per user per month for our 31 seats: $310 monthly or $3,720 annual. Asana Business at $24.99 per user per month: $774 monthly or $9,300 annual (more than 2.5 times the Jira bill). ClickUp Business at $12 per seat: $372 monthly. So Jira Premium is the cheapest of the credible options at our scale. Performance: page load on Jira issue view averages 1.1 seconds, peaks at 2.8 seconds on a board with 200+ visible issues. JQL queries against 50,000 issues complete in 400 to 800 ms which is acceptable. The web app feels fine if you use keyboard shortcuts. The mobile app on iOS feels slow and we mostly route around it as noted above.

Plan Per user per month (annual) Automation rules Best for
Free $0 Limited Up to 10 users, small project
Standard $7.16 1,700/month soft cap 10 to 30 users, single team
Premium $8.60 Higher caps Multiple teams, advanced roadmaps
Enterprise Contact sales Unlimited 100+ users, SCIM, audit logs

Pros and Cons

  • Pro: scales to many teams without per-team configuration sprawl if you stay disciplined
  • Pro: JQL plus automation is the highest-leverage feature pair at our scale
  • Pro: Atlassian ecosystem integrations (GitHub, Slack, Confluence) work well
  • Pro: Premium pricing is competitive at this team size
  • Con: global search degrades past 50k issues; force JQL on the team
  • Con: mobile app is the worst part of the platform
  • Con: someone must own admin work; budget about 4 hours per week per 25 engineers
  • Con: switching between Cloud and Data Center carries a real migration cost

Who This Is For

Pick Jira Cloud Premium if you have 15 or more engineers, you ship at least weekly, and you have someone who can own admin work for 4 to 8 hours a week. Pick Jira if your team is willing to learn JQL and live by saved searches. Pick Jira if you use other Atlassian products (Confluence, Bitbucket) or you want tight GitHub integration. Skip Jira if your team is under 10 engineers; Linear or even GitHub Issues plus Projects will be lighter and cheaper at that size. Skip Jira if no one wants to be the admin; without admin discipline, Jira sprawls into a hairball that nobody trusts in 18 months. Skip Jira if your culture is high-context and low-process; Jira rewards process discipline and you will fight the tool otherwise. Skip Cloud and pick Data Center if you have regulated workloads or strict data residency; Cloud's region controls are limited at Premium tier.

Pick fewer custom fields and more automation rules. The teams that drown in Jira are the ones that customised every project differently.

Bottom Line

Eighteen months in, Jira Cloud Premium is the right tool for our scale and we will likely stay on it past 50 engineers if the admin investment scales with us. The 11 hours per release saved by automation is the line that justifies everything else. The honest concerns: global search, mobile, and the slow migration cost between Cloud and Data Center if our compliance posture changes. The single best decision I made was to pick the Path B configuration philosophy in February 2025. Fewer fields, shared workflows, automation rules. The single worst decision I made was waiting too long (May 2025) to write the JQL training doc for new joiners. Two engineers churned out of frustration before I shipped it. Got a Jira sizing or migration question? Drop me a note. I will share the automation export and the JQL cheat sheet that turned new joiners into power users in week 2.