Jira workflow on a systems analyst interview

Why interviewers ask about Jira

When a systems analyst interview hits the "tell me about your tooling" segment, Jira is the default. Companies like Atlassian, Adobe, Cisco, and most of the F500 still run their delivery on Jira, and your interviewer wants to know whether you can configure it — not just click through it. They are testing whether you understand the issue hierarchy, the workflow states, and how to write a JQL query that does not return half the backlog.

A common warm-up is "draw me your team's workflow on a whiteboard." Candidates who freeze here are usually the ones who never owned a project in Jira — they only consumed it. The fix is to memorize one realistic workflow you have shipped and be ready to explain every transition, who triggers it, and which custom fields the transition depends on. That last detail is what separates a confident answer from a vague one.

If you are switching from Linear or Asana shops, the concepts map cleanly: Epic → Project, Story → Issue, Status → State. Show the interviewer you can translate, and you instantly look senior.

Issue hierarchy

Jira issues stack in a strict tree. The default tiers, from largest to smallest:

A clean tree for a fictional billing rollout at a SaaS like Notion or Linear might look like this:

Initiative: "Launch paid tiers across all surfaces"
  Epic: "Subscription billing v1"
    Story: "User can upgrade from Free to Pro"
      Sub-task: "Backend: POST /subscriptions"
      Sub-task: "Frontend: checkout modal"
      Sub-task: "QA: regression suite"
    Story: "User can cancel mid-cycle"
    Story: "Stripe webhook reconciliation"
    Bug: "Duplicate charge on retry after timeout"
    Spike: "Compare Stripe Tax vs Avalara for EU VAT"

The skill the interviewer is grading is decomposition discipline — you should never have a Story that is also tagged as a Task, and you should never have an Epic that fits in a single sprint. If your Epic closes in two weeks, it was a Story.

A typical workflow

Below is the workflow shape most teams converge on after one or two retros. Five to seven states is the sweet spot.

[Backlog] -> [To Do] -> [In Progress] -> [Code Review] -> [QA] -> [Done]
                  ^                                              |
                  +---------------- Reopened --------------------+

The key states, in plain English:

• Backlog — captured but not committed. Anything older than two quarters here is probably dead.
• To Do — pulled into the current sprint, waiting for someone to pick it up.
• In Progress — actively being worked. Only one issue per assignee should sit here at a time. If you see five, the assignee is multitasking and slipping.
• In Review — pull request open, waiting on reviewer. Tie this transition to a webhook from GitHub or GitLab so it updates automatically.
• In QA — built, deployed to staging, waiting for test. SA-written acceptance criteria become test cases here.
• Done — merged, deployed, verified. No exceptions.

Optional states worth knowing: Blocked, On Hold, Reopened, and Verified (for Bugs that need a second QA pass).

A team that runs the same workflow for Stories, Bugs, and Spikes is almost always a team that has never run a real retro.

Custom fields

Out of the box, every issue has Summary, Description, Assignee, Reporter, Priority, and Status. Real teams add fields for planning and traceability. Here is what shows up most often:

• Story Points — relative size, used for velocity. Fibonacci scale (1, 2, 3, 5, 8, 13) is the default.
• Acceptance Criteria — Given/When/Then or checklist. Owned by the SA.
• Affects Version / Fix Version — tells QA which build to test against.
• Components and Labels — slice the backlog by feature area or theme.
• Epic Link — connects a Story to its parent. Missing here means lost visibility.
• Sprint — auto-populated when the issue is pulled in.
• Severity — Bug-specific, distinct from Priority (severity is impact, priority is when we fix it).

SA-specific fields worth proposing in an interview answer:

• Source of requirement — stakeholder ticket, customer interview, compliance mandate.
• Stakeholder — who signs off on acceptance.
• Compliance flag — boolean for SOC 2, GDPR, HIPAA scope.

The bar for adding a field is brutal: if no one fills it in 90% of cases, delete it. A field nobody touches is worse than no field — it implies coverage that does not exist.

JQL basics

JQL — Jira Query Language — is how you find issues at scale. Interviewers love this one because they can hand you a scenario and watch you compose a query live. Memorize the building blocks.

project = "MOBILE" AND status = "IN Progress"

assignee = currentUser() AND sprint IN openSprints()

"Story Points" > 5 AND status != Done

priority = High AND created > -7d

The four queries every SA should be able to write under pressure:

-- My stories without acceptance criteria
issuetype = Story AND assignee = currentUser() AND "Acceptance Criteria" is EMPTY

-- All open bugs in the upcoming release
fixVersion = "v2.5" AND issuetype = Bug AND status != Done

-- Stale issues to triage
updated < -30d AND status in (Backlog, "To Do")

-- Cross-team dependencies for my epic
"Epic Link" = MOBILE-123 AND project != MOBILE

The operators worth knowing cold: =, !=, IN, NOT IN, ~ (contains), IS EMPTY, IS NOT EMPTY, WAS, CHANGED. The functions worth knowing: currentUser(), openSprints(), closedSprints(), now(), -7d, startOfMonth().

If an interviewer asks for "all issues a person worked on last quarter", the keyword is WAS — historical state queries are the JQL feature most candidates forget exists.

Alternatives: Linear, Asana, GitHub Projects

Not every shop runs Jira. If you are interviewing at a startup, you will likely see Linear or GitHub Projects; at agencies, Asana or monday.com. The interviewer's real question is: can you map your Jira experience onto their tool?

The honest answer in an interview is: the tracker matters less than the discipline. A team that owns its workflow on Notion outperforms a team that fakes process inside Jira. Say that out loud — interviewers respect it.

Common pitfalls

The first pitfall is one issue stuck in "In Progress" for two weeks. It usually means decomposition failed at refinement. Either the Story was too large and should have been split into sub-tasks, or the team treats "In Progress" as a parking lot. The fix is a hard rule: any issue past three days in progress triggers a standup conversation, and any issue past a sprint gets re-estimated or split.

The second is missing acceptance criteria on Stories. Engineers cannot know when "done" is reached, QA cannot write test cases, and PM cannot sign off. The fix lives in your Definition of Ready — no story enters a sprint without AC. SAs own this gate. If you want a deeper dive, see acceptance criteria with Given/When/Then.

The third is ignoring the Epic Link. A Story without an Epic is invisible to roadmap reporting and almost always gets prioritized incorrectly. Worse, you lose the ability to roll up progress for a stakeholder review. Make Epic Link a required field at issue creation time.

The fourth is custom-field bloat. Every well-intentioned PM adds a "Customer Impact" or "Risk Score" field, and within a year you have 40 fields nobody fills. The fix is an annual audit: any field below 30% completion gets deleted or made required. Tooling exists in Jira admin to report on field usage — use it.

The fifth is a workflow with 15+ statuses. Each added status feels safe, but the marginal status almost never carries information. Status proliferation usually traces back to one ops person who wanted visibility on a niche edge case. Five to seven statuses cover 90% of real work — anything beyond that needs a written justification.

The sixth, and the one that costs the most retrospective time, is no labels or components. Searching for "everything about checkout" requires a label or component; without one, your only option is full-text search on Summary, which misses half the relevant tickets. Set up your taxonomy on day one, not after the first quarterly review.

Related reading

• Acceptance criteria with Given/When/Then for systems analysts
• Definition of Ready and Done for systems analysts
• Case interview for systems analyst
• Architecture decision records for SA interviews

If you want to drill systems analyst interview questions like this every day, NAILDD ships daily SA practice questions covering exactly this pattern.

FAQ

Do I need Confluence alongside Jira?

Most teams pair them: Jira holds the issues, Confluence holds the long-form specs, runbooks, and decision logs. The link is bidirectional — a Jira issue references the Confluence page that birthed it, and the page links back to the implementing tickets. If your shop uses Notion or Google Docs instead, the pattern still holds — what matters is that requirements live in one place and issues live in another, with hard links between them.

Can I use GitHub Projects instead of Jira?

For small teams, open-source projects, or developer-heavy shops, absolutely. GitHub Projects gives you boards, custom fields, and views over issues and pull requests in the same surface engineers already use. The trade-off shows up at enterprise scale: GitHub Projects lacks complex workflow states, time-in-status reports, and the governance features auditors expect. If you are interviewing at a regulated company — fintech, healthcare, defense — assume Jira or a Jira-equivalent is the answer.

How granular should my workflow be?

The honest answer is as few states as you can defend. Start with five: To Do, In Progress, In Review, In QA, Done. Add a state only when the team is genuinely losing information by collapsing two stages. If you cannot point to a real conversation that would have been clearer with the new state, do not add it.

What is the difference between Priority and Severity?

Severity describes the impact on the user — Critical, High, Medium, Low. Priority describes the order in which the team will fix things — P0, P1, P2. A Critical-severity bug that affects 10 users on an obscure platform might be P2. A Medium-severity bug that hits the checkout flow during Black Friday is P0. Interviewers love this distinction because it tests whether you think like an engineer or like a product owner.

How do I prove Jira experience on a resume if my last shop used Linear?

State the concepts, not the tool. "Owned the issue lifecycle from refinement to release, including workflow customization, JQL-equivalent queries in Linear, and acceptance-criteria gates" lands better than "Used Linear." When the recruiter screens for "Jira," they are usually screening for a tracker-owner mindset — the tool is interchangeable.

Is JQL hard to learn?

No. The syntax is closer to SQL WHERE clauses than to a real query language, and the ten operators above cover ~95% of real-world queries. Block out an afternoon, open your team's Jira, and rewrite the saved filters from scratch — you will be fluent by the end.