4.5 Scrum and Kanban Board Configuration, Board Filters & Columns

4.5 Scrum and Kanban Board Configuration, Board Filters & Columns

Quick Summary: Agile boards in Jira Software Cloud provide the primary operational interface for development and business teams. Whether implementing iterative Scrum cadences or continuous Kanban flow, boards synthesize underlying project workflows, issue types, and fields into an intuitive visual paradigm. Jira administrators and board administrators must master the mechanics of board saved filters, column-to-status mappings, Work in Progress (WIP) constraints, the rightmost 'done' column rule, swimlanes, card customizations, and estimation settings. Understanding board governance and troubleshooting configuration bottlenecks is a core competency for the ACP-120 certification.

---

Scrum vs. Kanban Board Architecture

Jira Software Cloud provides two primary agile board templates for company-managed projects: Scrum boards and Kanban boards. While both visualize issues as cards progressing across columns, their operational lifecycles, planning mechanisms, and underlying metrics differ fundamentally.

+--------------------------------------------------------------------------+
|                       SCRUM VS. KANBAN ARCHITECTURE                      |
+--------------------------------------------------------------------------+
|  DIMENSION          | SCRUM BOARDS                | KANBAN BOARDS        |
|---------------------+-----------------------------+----------------------|
| Primary Cadence     | Time-boxed Sprints (1-4 wks)| Continuous Flow      |
| Planning View       | Dedicated Backlog Screen    | Optional Backlog     |
| Active Work View    | Active Sprints Board        | Kanban Board View    |
| Work Constraints    | Sprint Commitment Capacity  | Column Min/Max WIP   |
| Key Reports         | Burndown, Velocity, Epic    | Control Chart, CFD   |
| Work Completion     | 'Complete Sprint' Action    | Continuous Delivery  |
+--------------------------------------------------------------------------+

1. Scrum Boards: Iterative Delivery

Scrum boards are engineered for teams delivering work in fixed-duration increments called sprints:

• The Backlog View: Features two primary sections: the Sprint Planning container (where issues are sequenced into active or future sprints) and the Backlog container (the prioritized repository of uncommitted work).
• Sprint Lifecycle: Creating and starting a sprint requires the project-level Manage Sprints permission. When a sprint is started, its issues move to the Active sprints board view.
• Sprint Completion: When the sprint period ends, a user with Manage Sprints selects Complete sprint. Jira checks the status of all sprint issues: issues in the rightmost column are marked complete, while incomplete issues are moved to either a future planned sprint or returned to the backlog. Completing a sprint permanently records metrics in the Velocity Chart and Burndown Chart.

2. Kanban Boards: Continuous Flow

Kanban boards are designed for teams whose work arrives continuously, such as DevOps, IT operations, maintenance, or support teams:

• No Sprints: Work moves across the board based on team capacity and priority without time-boxed sprint commitments.
• Kanban Backlog: By default, Kanban boards display all uncompleted issues directly on the main board. However, administrators can enable a dedicated Kanban backlog (via Board settings > Columns, dragging statuses into the Kanban backlog panel) to separate unrefined incoming requests from actively prioritized work.
• Flow Metrics: Performance is tracked using the Control Chart (measuring cycle time and lead time) and the Cumulative Flow Diagram (CFD) (visualizing work volume across statuses over time).

---

Board Filters, Ownership & Governance

Every agile board in Jira Cloud is powered by an underlying saved filter written in Jira Query Language (JQL). Navigating to Board > '...' (More options) > Board settings > General reveals the filter configuration.

+--------------------------------------------------------------------------+
|                    BOARD FILTER & GOVERNANCE HIERARCHY                   |
+--------------------------------------------------------------------------+
|   [ SAVED FILTER (JQL) ]  --> Defines issue dataset (universe of issues) |
|             |                                                            |
|             v                                                            |
|   [ FILTER SHARE PERMISSIONS ] --> Controls WHO CAN VIEW the board       |
|             |                                                            |
|             v                                                            |
|   [ BOARD ADMINISTRATORS ]    --> Controls WHO CAN CONFIGURE board       |
|                                   (Columns, Swimlanes, Estimation)       |
+--------------------------------------------------------------------------+

Saved Filter Mechanics

The board filter determines which issues are pulled into the board across all projects. A board filter can query a single project (project = PROJ ORDER BY Rank ASC), multiple projects (project IN (IOS, ANDROID) ORDER BY Rank ASC), or arbitrary criteria (type IN (Bug, Incident) AND priority = High).

[!IMPORTANT] Every agile board filter must conclude with an explicit ranking clause: ORDER BY Rank ASC. Jira's agile ranking engine allows users to visually drag and drop cards to change priority order. If the ORDER BY Rank ASC clause is removed or replaced with another sort field (such as ORDER BY created DESC), manual card ranking becomes disabled on the board.

Filter Permissions vs. Board Visibility

A common administrative issue occurs when users report that a board is missing or displays an "Access Denied" error. Board access is directly coupled to the underlying saved filter's share permissions:

• If the saved filter is private (shared only with the creator), no other user can see the board, even if they are Jira Administrators or Project Administrators.
• To make a board visible to team members, the saved filter must be shared with the relevant Project, User Groups, or the entire Organization under Filters > View all filters > Filter Details > Edit permissions.

Board Administrators vs. Project Administrators

Board configuration rights are separate from project permissions:

• Board Administrators: Defined under Board settings > General > Administrators. Board administrators can be specific users or user groups. They possess the authority to modify board columns, WIP limits, swimlanes, card colors, card layouts, and estimation statistics.
• Project Administrators: Having the Administer Projects permission in a project does not automatically grant board administrator rights on boards referencing that project.
• Jira Administrators: Users with the global Administer Jira permission can configure any board across the instance, even if they are not explicitly listed as a board administrator.

The Kanban Board Sub-Filter

In a continuous flow Kanban environment, completed issues would accumulate indefinitely, causing browser performance degradation and visual chaos. To solve this, Jira provides a Board Sub-filter (Board settings > General > Board sub-filter).

• The sub-filter appends an additional JQL condition strictly to the active Kanban board view without altering the primary board filter or reporting metrics.
• Default sub-filter JQL:

  fixVersion in unreleasedVersions() OR fixVersion is EMPTY
  

• If an organization does not use Fix Versions, administrators can configure the sub-filter to prune resolved issues older than a specific timeframe:

  status NOT IN (Closed, Done, Resolved) OR resolved >= -14d
  

---

Column Configuration, Status Mapping & WIP Limits

Columns represent visual stages of progress. Configuring columns is performed under Board settings > Columns.

+--------------------------------------------------------------------------+
|                   COLUMN MAPPING & STATUS CATEGORIES                     |
+--------------------------------------------------------------------------+
|  UNMAPPED STATUSES  |  TO DO COLUMN   | IN PROGRESS COL  |  DONE COLUMN  |
|---------------------+-----------------+------------------+---------------|
|  [On Hold]          |  [Open]         |  [In Dev]        |  [Resolved]   |
|                     |  [Ready]        |  [Code Review]   |  [Closed]     |
|                     |                 |  [QA Testing]    |               |
|---------------------+-----------------+------------------+---------------|
| Issues NOT shown    | Gray Category   | Blue Category    | Green Category|
| on the board!       | (To Do)         | (In Progress)    | (Done)        |
+--------------------------------------------------------------------------+

Status-to-Column Mapping Rules

1. Unmapped Statuses: Any workflow status left in the "Unmapped statuses" area doesn't appear on the board. Issues in an unmapped status disappear from the board view and don't count as complete when a sprint closes.
2. Multiple Statuses per Column: Administrators can drag multiple statuses into a single column (e.g., mapping both In Dev and Code Review into an In Progress column). When a user drags a card into that column, Jira prompts them to select the specific destination status if multiple transitions are possible.
3. Left-to-Right Ordering: Columns are sequenced from left to right, representing the team's definition of workflow progression.

Work in Progress (WIP) Limits

Kanban methodology relies on WIP limits to identify bottlenecks, eliminate multitasking, and optimize throughput. In Jira, administrators set Min and Max constraints per column:

• Maximum WIP Limit: Specifies the maximum number of issues allowed in the column simultaneously. If the limit is exceeded, the column header is highlighted in red.
• Minimum WIP Limit: Specifies the minimum number of issues required to keep downstream workers utilized. If the count drops below the minimum, the column header is highlighted in yellow.
• Soft Enforcement: WIP limits in Jira Cloud are advisory visual alerts. Jira does not block users from dragging cards into an overloaded column; it alerts the team visually to swarm on the bottleneck.
• Constraint Basis: WIP limits can be evaluated based on Issue Count (counting all parent and sub-task cards), Issue Count excluding sub-tasks, or by the configured Estimation Statistic (e.g., total Story Points).

The Rightmost Column Means "Done"

The rightmost column carries unique significance:

• Completion rule: Atlassian states that Jira only considers issues in the rightmost column as complete. The column is always shown green, and middle columns are blue.
• Map every finished status there: statuses such as Done, Cancelled, or Won't Do belong in the rightmost column. If "Resolved" sits in a middle column, completing the sprint treats those issues as incomplete and offers to move them to the backlog or next sprint. Issues in unmapped statuses aren't counted as complete either.
• Resolution is separate: moving a card into the rightmost column doesn't set the Resolution field unless the transition does so (with a screen or an Update field action). Configure it anyway, because resolution drives strikethrough, Created vs. Resolved reports, and "open issue" filters.

---

Swimlanes, Card Colors & Card Layout

Agile boards provide visual dimensions to categorize, prioritize, and highlight work.

---

Estimation & Time Tracking Configuration

Configured under Board settings > Estimation, this tab governs how work effort is measured, planned, and tracked across the agile lifecycle.

+--------------------------------------------------------------------------+
|                       ESTIMATION CONFIGURATION OPTIONS                   |
+--------------------------------------------------------------------------+
|  ESTIMATION STATISTIC          |  TIME TRACKING OPTION                   |
|--------------------------------+-----------------------------------------|
|  • Story Points (default)      |  • None                                 |
|  • Original Time Estimate      |  • Remaining Estimate and Time Spent    |
|  • Issue Count                 |                                         |
|  • None                        |                                         |
+--------------------------------------------------------------------------+

1. Estimation Statistic

The estimation statistic determines the metric used to calculate sprint velocity, burndown, and capacity:

• Story Points: The agile standard. Used to estimate relative complexity on parent issues. Story points on sub-tasks do not aggregate to the parent on company-managed Scrum boards.
• Original Time Estimate: Uses hours and days. Velocity and burndown reflect time durations.
• Issue Count: Every issue equals 1 unit. Useful for teams practicing Lean or Kanban that do not size individual stories.
• None: Disables estimation tracking entirely.

2. Time Tracking Setting

Governs how time tracking metrics display on cards and report panels:

• None: Agile reporting relies solely on the primary Estimation Statistic.
• Remaining Estimate and Time Spent: Displays time-tracking progress bars on cards and allows burndown charts to evaluate remaining hours alongside story points.