Jira's vocabulary is dense - some terms are agile concepts (epic, story, sprint), some are Jira-specific configuration objects (screen, scheme, workflow), and some mean different things in different contexts. This glossary cuts through that by giving each term a short definition you can lift verbatim into your team's documentation, plus a longer explanation of how it actually behaves in a real Jira project.
Agile & Scrum
Backlog
A Jira backlog is the ordered list of issues that aren't yet in an active sprint - the team's queue of upcoming work. The backlog is ranked top-to-bottom by priority, so the next sprint can be planned by pulling from the top until story-point capacity is reached. Every Scrum board has a backlog view; Kanban boards can enable one optionally.
Read definition →Board
A Jira board is a visual view of issues filtered by a saved JQL query, organised into columns that map to workflow statuses. Jira supports two board types: Scrum boards (with sprints, backlog, and a velocity chart) and Kanban boards (continuous flow with WIP limits). A board belongs to one or more projects and is the day-to-day working surface for most agile teams.
Read definition →Definition of Done
The Definition of Done (DoD) is a Scrum team's shared checklist of conditions an issue must satisfy before it can be moved to Done. Typical items include code merged, tests passing, documentation updated, release notes drafted, and product-owner acceptance. The DoD lives outside Jira - on a wiki page or sprint goal board - and is referenced during sprint review and backlog refinement.
Read definition →Definition of Ready
The Definition of Ready (DoR) is a Scrum team's shared checklist of conditions a backlog item must satisfy before it can be pulled into a sprint. Typical items include having acceptance criteria, an estimate, dependencies identified, and a clear owner. The DoR prevents under-refined work from entering the sprint and stalling mid-flight, and is applied during backlog refinement and sprint planning.
Read definition →Epic
A Jira epic is a large body of work that spans multiple sprints and is broken down into smaller stories, tasks, or bugs that share an Epic Link. Epics represent feature-level outcomes - 'Customer self-service portal' or 'Migrate to Postgres 16' - not single deliverables, and typically span weeks to months.
Read definition →Sprint
A Jira sprint is a fixed-length iteration - usually 1 to 4 weeks - during which a Scrum team completes a committed set of issues from the backlog. Sprints have a defined start and end date, a sprint goal, and a finite list of issues that move together through the team's workflow board until the sprint closes.
Read definition →Story Points
Story points are a unit of relative estimation in Jira - they measure how big or complex one issue is compared to another, not how many hours it will take. Teams pick a scale (most use the Fibonacci sequence: 1, 2, 3, 5, 8, 13) and assign points during refinement. Velocity, burndown, and sprint capacity reports all depend on the Story Points field.
Read definition →Swimlane
A swimlane in Jira is a horizontal grouping on a board that splits issues into named rows based on a chosen attribute - assignee, epic, priority, queries, or no grouping. Swimlanes cut across all columns of the board, so each row shows one group's issues moving from To Do to Done. Common uses include grouping by epic during sprint work or by priority for incident triage.
Read definition →User Story
A Jira user story is a single, sprint-sized requirement written from the user's perspective in the form 'As a [persona], I want [capability], so that [outcome].' Stories are the most common child of an epic and the most common parent of a set of sub-tasks. A story should fit in one sprint and have one accountable assignee.
Read definition →Velocity
Velocity in Jira is the average number of story points a Scrum team completes per sprint, calculated as a rolling average across the last several sprints (commonly three to five). Jira's Velocity Chart shows committed versus completed points sprint over sprint, and teams use the rolling average to forecast how much work to pull into the next sprint.
Read definition →Issue Types & Hierarchy
Issue Type
An issue type in Jira is the category that classifies what kind of work an issue represents - Bug, Story, Task, Epic, Sub-task are the standard ones, but admins can create custom types like Incident, Change Request, or Vulnerability. Issue type controls which screen, workflow, and field configuration applies to the issue.
Read definition →Linked Issues
Linked issues in Jira are explicit relationships between two issues, expressed as a typed link such as 'blocks,' 'is blocked by,' 'relates to,' 'duplicates,' or 'is cloned by.' Unlike the parent/child sub-task relationship, links are bidirectional, work across projects, and form a graph rather than a tree. Admins can define custom link types under Issue Linking.
Read definition →Sub-task
A Jira sub-task is a child issue attached to a single parent (a Story, Task, Bug, or custom standard-level issue). Sub-tasks break the parent's work into smaller steps - design, build, test, document - so individual team members can claim and track each piece without losing the parent context. Sub-tasks belong to the same project as their parent and inherit several fields.
Read definition →Configuration
Attachment
An attachment in Jira is a file uploaded to an issue - screenshot, log file, document, video. Attachments are stored alongside the issue and visible to anyone who can see the issue itself. Admins control which file types are allowed and how large files can be. Attachments are governed by the issue's permission scheme and don't have their own access controls.
Read definition →Component
A component in Jira is a project-level tag that groups issues by the part of the product they affect - e.g., 'checkout-service', 'mobile-app', 'billing-api'. Components can have a default assignee and a component lead, which Jira uses to automatically route new issues. Components are defined per-project and don't cross project boundaries by default.
Read definition →Custom Field
A custom field in Jira is any field added to issues beyond Jira's built-in set of summary, description, priority, assignee, etc. Custom fields can be text, number, dropdown, multi-select, user picker, date, cascading select, or several other types. They're managed in Jira admin and exposed on screens via a Field Configuration.
Read definition →Screen
A Jira screen is the configurable ordered list of fields that appears when a user creates, edits, or views an issue. Screens decide which fields a reporter sees on Create Issue and which fields appear on the issue's detail view. Different issue types and different operations (Create / Edit / View) can use different screens via Screen Schemes.
Read definition →Workflow
A Jira workflow is the set of statuses an issue can occupy and the transitions allowed between them. Every issue type in every project has a workflow - even a default 'To Do / In Progress / Done' is a workflow. Admins design workflows with conditions (who can transition), validators (what must be true), and post-functions (what happens automatically) on each transition.
Read definition →Querying & Reporting
Dashboard
A Jira dashboard is a personal or shared landing page made up of gadgets - small widgets that visualize filter results, sprint progress, assigned issues, or charts. Dashboards are owned, share-scoped, and built on top of one or more saved filters. They're the standard way teams expose Jira data to non-Jira-power-users.
Read definition →Filter
A Jira filter is a saved JQL query. Filters are first-class objects with owners, share permissions, and subscriptions - they back agile boards, dashboard gadgets, scheduled email reports, and automation rules. The filter, not the underlying query, is what other Jira objects reference, so renaming a filter doesn't break the things that consume it.
Read definition →JQL
JQL stands for Jira Query Language. It's the SQL-like query syntax used to search and filter issues in Jira - 'project = WEB AND status = Open AND assignee = currentUser()'. JQL powers saved filters, dashboard gadgets, agile boards, automation conditions, and the issue search bar. Learning JQL is the single highest-leverage Jira skill.
Read definition →Workflow & Tracking
Automation Rule
A Jira automation rule is a no-code workflow that triggers actions when issues change. Each rule has one trigger (issue created, transitioned, commented, scheduled, etc.), optional conditions and branches, and one or more actions (transition, edit field, create issue, send email, call webhook). Rules are configured in project or global automation settings and execute server-side without user intervention.
Read definition →Comment
A comment in Jira is a free-text note added to an issue, attributed to the author and timestamped. Comments support rich text, mentions (@user), inline attachments, and visibility restrictions to specific roles or groups. Comments form the main audit trail of decisions, questions, and updates on an issue - and on most issues, they're the most-edited part of the record.
Read definition →Epic Link
Epic Link is the Jira field that connects a story, task, or bug to its parent epic. On Jira Data Center it's a dedicated custom field named 'Epic Link.' On Jira Cloud the same relationship is expressed via the standard `parent` field after the platform's hierarchy refactor. Either way, Epic Link is how child issues roll up to an epic for reporting, burndown, and roadmapping.
Read definition →Parent Issue
A parent issue in Jira is the issue that sits one level above another in Jira's hierarchy. A sub-task's parent is its standard-level issue (Story / Task / Bug); on Jira Cloud, a standard issue's parent is its epic. The parent relationship is one-to-many: a parent can have many children, but each child has exactly one parent.
Read definition →Priority
Priority in Jira is a built-in field that captures how urgently an issue should be worked - Highest, High, Medium, Low, Lowest by default, configurable per instance. Priority is for scheduling decisions (what do we do next?), not for measuring user impact (use Severity for that). Priority schemes can assign different priority sets to different issue types or projects.
Read definition →Resolution
Resolution is a built-in Jira field that captures *how* an issue ended - Fixed, Won't Do, Duplicate, Cannot Reproduce, Done. An issue is considered 'resolved' once its Resolution is set to any non-empty value; until then it counts as open regardless of its Status. Most workflow misconfigurations in Jira trace back to a transition that didn't set Resolution.
Read definition →Status
A Jira status is the current workflow state of an issue - for example To Do, In Progress, Code Review, Done. Statuses are nodes in a workflow, connected by transitions that move issues between them. Every issue is in exactly one status at any time, and every status belongs to one of three status categories: To Do, In Progress, or Done.
Read definition →Status Category
A status category in Jira is one of three fixed groupings that every status belongs to: To Do, In Progress, or Done. Categories drive board column defaults, reporting (velocity, burndown), and JQL functions like `statusCategory = Done`. The category is set per status; misclassifying a custom status into the wrong category silently breaks reports.
Read definition →Version
A version in Jira (also called a release or fix version) is a project-level grouping of issues that will ship together. Versions have a name, optional start and release dates, and a status (unreleased, released, archived). The Fix Version/s and Affects Version/s fields on issues tie them to specific versions for release planning and bug-tracking.
Read definition →Watcher
A watcher in Jira is a user who has subscribed to an issue and receives email notifications when it changes. Watchers can be added explicitly or auto-added by Jira (assignee, reporter, voters, depending on the project's notification scheme). Watchers don't gain any extra permissions; they just get notifications - and watching is the most common way users keep tabs on issues without being assigned to them.
Read definition →Service Management
JSM Queue
A JSM queue is a saved JQL-backed view of service-desk tickets in Jira Service Management, organised so agents can see what to work on next. Each queue has a name, a JQL filter, a set of displayed columns, and an ordering. Queues are project-specific, configured by JSM project admins, and form the agent's primary workspace - replacing the issue navigator for day-to-day service work.
Read definition →SLA
An SLA (Service Level Agreement) in Jira Service Management is a configured time target for responding to or resolving customer tickets. Each SLA has a goal (e.g., respond within 4 hours), calendar (business hours), conditions (which tickets it applies to), and start/pause/stop triggers. SLAs feed queue columns, reports, and breach notifications, and are central to JSM's service-desk model.
Read definition →Configuration & Permissions
Label
A label in Jira is a free-form tag attached to an issue, used for ad-hoc categorisation. Labels are created on the fly by any user with edit permission - no admin setup, no controlled vocabulary. Multiple labels can be applied per issue, and they're fully searchable in JQL via `labels = ...`. Labels are global across the instance, so the same label string is shared by every project that uses it.
Read definition →Notification Scheme
A notification scheme in Jira is a named set of mappings from events (Issue Created, Issue Updated, Issue Commented, etc.) to the recipients notified by email. Each project is assigned one notification scheme. Recipients can be roles, groups, individual users, reporter, assignee, watchers, or current assignee. Schemes are reusable across projects, so editing one scheme affects every project that uses it.
Read definition →Permission Scheme
A permission scheme in Jira is a named set of mappings from permissions (Create Issues, Edit Issues, Transition Issues, etc.) to the users, groups, or project roles that can perform them. Each project is assigned exactly one permission scheme. Schemes are reusable: one scheme can be shared by many projects, so a single edit propagates everywhere it's used.
Read definition →Project Role
A project role in Jira is a named bucket of users and groups that's defined globally but populated per project. Default roles include Administrators, Developers, and Users; admins can add more (e.g., QA, Stakeholders). Project roles are referenced from permission schemes, notification schemes, and workflow conditions - so adding a user to a role grants the access that role's permissions describe.
Read definition →Estimation & Reporting
Story Estimate
A story estimate in Jira is the size assigned to a backlog item before it's worked, usually in story points but sometimes in hours, t-shirt sizes, or a custom unit. The estimate goes in the Story Points field (or a configured custom estimation field) and feeds velocity charts, burndown reports, and sprint capacity planning. Estimates are relative measures of effort, complexity, and uncertainty - not time.
Read definition →Time Tracking
Time tracking in Jira is the system that records actual time spent on issues, alongside original and remaining estimates. Users log work as Work Log entries on each issue; Jira aggregates the totals into Original Estimate, Time Spent, and Remaining Estimate. Time tracking is project-scoped (can be enabled or disabled per project) and is the basis for cost reports, client billing, and effort retrospectives.
Read definition →Work Log
A work log in Jira is a single entry recording time spent on an issue by one user on a specific date, with optional comment. Work logs sum to the issue's Time Spent field and aggregate across issues, projects, and users for reporting and billing. Each entry has a timestamp, duration, author, optional description, and an optional adjustment to Remaining Estimate.
Read definition →