Jira Expert

JQL Query Library — Sprint Reporting

1. All stories in the current sprint:

project = MYPROJ
AND issuetype = Story
AND sprint in openSprints()
ORDER BY priority ASC

2. All open P0 bugs (any sprint):

project = MYPROJ
AND issuetype = Bug
AND priority = Highest
AND statusCategory != Done
ORDER BY created DESC

3. Everything assigned to a specific person, updated this week:

project = MYPROJ
AND assignee = "jane.doe@company.com"
AND updated >= startOfWeek()
AND statusCategory != Done
ORDER BY updated DESC

Replace email with currentUser() to make it work for whoever is logged in.

4. Issues added to current sprint after it started (scope creep detection):

project = MYPROJ
AND sprint in openSprints()
AND sprint not in closedSprints()
AND issueFunction in addedAfterSprintStart()
ORDER BY created DESC

Requires ScriptRunner or Jira Advanced Roadmaps.

Alternative for scope creep (native Jira):

project = MYPROJ
AND sprint in openSprints()
AND created >= "2025-03-03"
ORDER BY created DESC

Pro tip: Save these as Jira filters, then build a dashboard with Issue Statistics and Sprint Health gadgets pointing to these filters. Instant weekly reporting with no manual effort.

Going from one team to five is where most Jira setups break. The instinct is to create five new projects and split the work. That solves one problem and creates three new ones.

Project structure options

One project per team (what most people default to): Clean ownership, easy board management. The problem is cross-team epics require five separate epics with manual syncing, dependencies are invisible, and reporting across teams requires JQL gymnastics.

One project per product area (recommended for your situation): Group teams by what they're building together, not by their org chart. For five teams — frontend, backend, data, mobile, platform — a reasonable structure might be:

• PRODUCT — frontend, backend, mobile work (consumer-facing features)
• PLATFORM — platform team work (infrastructure, shared services)
• DATA — data team work (pipelines, analytics, ML)

Three projects instead of five. Frontend, backend, and mobile use components within PRODUCT to differentiate their work. This keeps cross-team feature work in the same project (shared epics, shared board) while maintaining team-level visibility via component filters.

Team + components is a hybrid: one project, all five teams, with components as team identifiers. Works well under 30 people total. At 5 teams it becomes noisy — sprint boards pull from a single backlog and filtering overhead is constant.

Cross-team dependency tracking

Use Jira's built-in "is blocked by" / "blocks" link types — they're underused. When backend creates a ticket that frontend depends on, the frontend ticket gets a is blocked by BACKEND-123 link. This surfaces in the issue view and in JQL.

Create a dependency board: a Jira board with the saved filter:

project in (PRODUCT, PLATFORM, DATA)
AND issueType = Story
AND issue in linkedIssues("is blocked by")
AND statusCategory != Done

This shows every in-flight ticket that's blocked, across all teams, on one board. Make it a shared bookmark in your team's Slack or Confluence. Review it in weekly cross-team syncs.

The platform team problem

Platform team work (enablers) is tricky: it's not driven by user stories, it unblocks multiple teams, and it often has no direct product owner. Model it as:

• Enabler epics in the PLATFORM project, labeled enabler
• Each enabler epic links to the product team tickets it unblocks: PLATFORM-45 blocks PRODUCT-310
• Platform team's sprint board shows enablers; product teams' boards show their blocked tickets

Avoid having the platform epic live in the product project. The platform team doesn't own the product backlog. Keep ownership clean: the project the epic lives in is the team responsible for it.

Label and component taxonomy

Standardize across all projects before they diverge. Proposed convention:

Components (team/area identifiers): frontend / backend / mobile / platform / data

Labels (cross-cutting concerns):

• tech-debt — non-feature improvements
• security — security-related work
• cross-team — requires coordination with another team
• customer-escalation — triggered by a customer issue

Issue types: use Jira defaults (Story, Bug, Task, Sub-task, Epic) consistently. Avoid creating custom issue types unless essential — they multiply fast and become orphaned.

The cross-team label is especially useful: filter for it weekly to surface coordination work before it becomes a blocker.

Epic ownership across teams

When a feature requires frontend, backend, and mobile: the Epic lives in the product area project (PRODUCT) and is owned by the PM driving the feature — not the engineering team. Sub-tasks and stories for each team are created in the same project, assigned to the relevant component, and linked to the parent epic.

Do not create three epics (one per team) for the same feature. That's the pattern that produces duplicate tickets and unclear ownership. One epic, one owner, multiple stories assigned to different components.

Automation for cross-team work

Two high-value automation recipes in Jira's built-in automation engine:

Auto-create team tickets from a cross-team epic:

• Trigger: Epic created with label cross-team
• Action: Create linked stories in each affected project (use the Create issue action with Epic Link set to the parent epic)

Notify on blocker status change:

• Trigger: Issue status changes (any → any) where issue has blocks link type
• Action: Add comment and @ mention assignee of the blocked ticket: "Blocking issue [KEY] moved to [Status]. Review if your work can proceed."

Both are native Jira automation — no third-party apps needed.

Phased migration plan

Don't restructure during an active sprint. The sequence:

Week 1 — Audit and plan:

• Map all existing tickets to the new project structure on paper
• Identify active sprints and their end dates
• Create new projects (don't migrate yet)

Week 2 — After sprints close:

• Bulk-move completed historical tickets to appropriate new projects (use Jira's bulk edit: select tickets → Move)
• Leave in-progress tickets in the old project until they close

Week 3 — Cut over:

• New work starts in new projects
• Old project becomes read-only (restrict permissions, don't delete — history is valuable)
• Update Confluence space links and Slack integrations to point to new boards

History is preserved because Jira moves tickets with their full history intact. Nothing is lost.

What does your current sprint cycle look like, and do teams share a sprint cadence or run independently?