Short definition
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.
Scrum vs. Kanban boards
The fundamental difference is time-boxing:
- Scrum boards organise work into sprints of fixed length (usually two weeks). Stories are pulled from a backlog into a sprint, worked, and either finished or carried over. The board shows the current sprint’s issues; the backlog view shows everything else. Velocity Chart, Sprint Report, and Burndown Chart are Scrum-only.
- Kanban boards have no sprints. Issues flow continuously from To Do through In Progress to Done. WIP (work-in-progress) limits cap how many issues can sit in any one column. Cumulative Flow Diagram and Control Chart are Kanban-friendly reports.
Many teams use both: a Scrum board for delivery work and a Kanban board for support / ops in the same project.
Board configuration
A board’s behaviour is defined by:
- The filter - the JQL query that defines which issues belong to the board.
- Columns - the visual lanes. Each column maps to one or more workflow statuses.
- Swimlanes - horizontal groupings within the board (by epic, assignee, priority, JQL, etc.).
- Quick filters - one-click JQL overlays (“My Issues,” “Unassigned,” “Blocked”).
- Card layout - which fields appear on the card preview (priority, assignee avatar, story points, due date).
Changes to board configuration affect only the board view - they don’t change underlying issue data or the workflow.
Permissions and ownership
A board has an administrator (the user who created it, by default) who can change the filter, columns, and swimlanes. Anyone with permission to view the underlying issues can view the board. This separation matters: a board’s administrator can show you fewer issues than the project would otherwise show, but not more.
Common board pitfalls
Two patterns recur:
- Filter creep. The board’s JQL filter slowly accretes exceptions (“but not these labels, except from this project, unless…”) and becomes unreadable. Refactor it periodically; the board exists to show the team’s work, not to encode every nuance.
- Column-to-status mapping drift. New statuses get added to the workflow but nobody updates the board, so issues vanish from the board view (Jira parks them in an “Unmapped” lane that nobody notices). Whenever the workflow changes, check the board’s column mapping.
Common questions
What is a board in Jira?
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.
What's the difference between a Scrum board and a Kanban board?
A Scrum board organises work into fixed-length sprints with a backlog, sprint planning, and a velocity chart. A Kanban board is a continuous flow with no sprints, WIP limits per column, and a cumulative flow diagram. Scrum suits teams delivering on a regular cadence; Kanban suits ops, support, and incident-response teams where work arrives unpredictably.
Can one board cover multiple Jira projects?
Yes. A board's source is a JQL filter, and the filter can include `project in (ABC, DEF, GHI)`. Multi-project boards are common when a single team works across several projects or when a programme-level view is needed. Permissions still apply - users only see issues they have permission to view.
How are board columns mapped to statuses?
Each board column is mapped to one or more workflow statuses in board configuration. A column called 'In Progress' might map to In Progress, Code Review, and Testing statuses. Issues in any of those statuses appear in that column. This decouples the team's visual workflow from the underlying status set.