Blog Barista: Sam Nadarajan | March 17, 2020 | Developer Tools | Brew time: 10 min

Welcome back to the Jira 201 series. In Part 1, we went over a lot of information about the different and extensive levels of configurations for projects. In today’s post, we’ll take a look at what you can do as a Jira Board Administrator.

Let’s say you’ve just been tasked with serving as the administrator for a Jira board on your development team. Your Jira Administrator has made you the board administrator for a particular board, and now you are tasked with configuring it to work for your team. However, you are brand new to the world of board administration. What can you do as a board administrator? 

By the time you finish reading this post, you will be comfortable with configuring your board in a way that achieves clarity and efficiency for your team. 

Note: All screenshots are provided from Jira Software v8.5.1. This post does not include specific configurations for the next-generation boards exclusively available in Jira Cloud, however, many of the same properties are available for both types.

Configurations

Jira provides a significant amount of control to board administrators. Remember that there are two different types of boards in Jira Software: Kanban and Scrum. Board configurations are the same for these two types of boards, except for the Estimation configuration which is only available for a Scrum board.

General Configurations

General configurations cover administrative details for the board and the filter that drives the board. All boards are driven by a filter – even when you create a board from an existing project, Jira will automatically create a filter (e.g. project = <your project here>) for you when you create a board but if you need more control you can change your filter configuration. As an administrator, you can change the name of the board and who can be a board administrator. The other configurations in this section largely deal with filter configurations, such as the filter query and permissions.

You may be wondering what Jira means by “Ranking.” Rank refers to the location of a Jira issue in the backlog. Jira uses a rank index to determine the location of a Jira issue relative to another. If the filter that drives your board ends with ORDER BY RANK, then ranking is enabled for your board. If ranking is enabled for your board, you can drag and drop issues above or below other issues in your backlog to prioritize them. If ranking is disabled (e.g. filter query ends with ORDER BY PRIORITY ASC), then you will not have the ability to drag and drop issues in your backlog. If you wanted to move issues up or down, you would have to change the field value specified in the ORDER BY clause of your query (e.g. in this case, change the priority of the issue). Most teams will utilize the ranking feature so they can easily prioritize the backlog.

Column Configurations

Column configurations allow you to map statuses in your workflow(s) to columns on the board. Jira issues change statuses until they are complete so mapping statuses to columns allows you to quickly see where an issue is in your process just by looking at your board. Here is an example of what this configuration screen looks like:

There are a handful of different configurations on this board, here’s a brief explanation of each one:

Column Constraint

Let’s say you want to minimize the number of issues that appear in each column. The column constraint option allows you to determine how to calculate the number of issues in each column and also set a minimum/maximum value for each column. Within this dropdown, you can choose to count issues in a column based on the number of issue cards, or the number of issue cards excluding subtasks. 

If you choose to constrain issues based on the number of issue cards, this is what an example board would look like. Note the subtask in the “In Progress” column is included in the count:

If I change the Column Constraint to exclude subtasks, the column count will exclude subtasks as illustrated below:

If you want to set minimum and maximum values for each column, you can do so when you determine how to count issues. This will create a visual indicator on your board indicating a breach in the column. For example, if I set the maximum number of issues (including subtasks) for the “In Progress” column to 3, if 4 issues end up in that column this is what the board will display:

While no hard restriction is enforced (your team could move more than 3 issues in to the “In Progress” column), this visual indicator can serve as a reminder to address the problem after standup or during another team meeting. These indicators are especially helpful if your team practices the “Limit Work In Progress” Kanban principle.

Days in Column

A visual row of dots will appear at the bottom of cards on the board to identify issues that have seen no movement on the board after a time. The row of dots becomes longer the more time an issue spends in a particular status, nudging your team to address it:

Simplified Workflow

The Simplified Workflow means that the project used in your board has a workflow consisting of a handful of statuses that issues can move freely between. On the board, when you drag an issue, you will be able to drag it to any column. Your project or Jira administrator can configure the workflow to be simpler if necessary. However, unless your Jira project is small, the workflow your Jira project is using will probably not be that simple.

Status Mapping

All statuses available within your project’s workflow are available for you to map to different columns. Merely drag and drop statuses from the right to columns on the left. As issues change statuses, they will appear in these respective columns. If a column is not mapped to a status, that column will not appear on the board.

Swimlane Configurations

Swimlanes represent horizontal divisions on your board that issues can flow through. Multiple swimlanes can be configured to reflect team structure, priority of work, or other properties that make the board visible and clear. You have the ability to add swimlanes based on a number of different options, as illustrated below:

Here is an example of a swimlane configuration by query for High Priority tickets. This configuration will show High priority issues at the top in their own swimlane, with all other issues appearing below:

Below is an example of what the swimlane will look like on the board. 

Quick Filter Configurations

Quick Filters allow board users to quickly identify certain issues on the board. When a new board is created in Jira Software, two default quick filters are automatically created for you, as illustrated below:

Additional quick filters can be added, or existing quick filters can be removed based on the objectives of the board. Quick filters are also stackable, meaning you can select multiple quick filters to drill down to the subset of Jira issues you need to view. In the example above, if you select both the “Only My Issues” and “Recently Updated” quick filters, you would only see issues assigned to you that were updated within the past day.

Card Colors Configuration

Card colors can serve as a quick visual way to identify issues on your board. Here’s an example of the different ways you can configure card colors:

When selected, the left border of an issue card on the board will reflect the color of the configuration. Here’s an example of a board configured with card colors based on priority and how it would appear on the board:

Note: High priority items have a different card color than the low priority cards.

Card Layout Configuration

Issue cards in the backlog and board view show limited information. You will not find much more information outside of the issue key, issue type, priority, summary, and estimate fields. However, board administrators have the ability to display additional fields that can be viewed across issues at a glance, instead of clicking into each card. Here’s an example of what the card layout configuration looks like:

There are two different views that additional fields can be added for: the backlog view and the board view. In the example here, the Fix Version/s and Component/s fields have been added to the backlog view. Now, when viewing the backlog, you will see these additional fields displayed for each issue card without having to click into them:

1.1 is the Fix Version that EXMPL-2 is associated with, and Accounts is a component on the issue.

Here is what the board would look like with additional fields added to the card:

The issue type and due date will appear for each card in the board view.

While Jira offers some flexibility for card layout configurations, limitations are put in place to prevent your board from becoming cluttered. Note that as you add each field, the card size becomes larger. As a result, a backlog of 100 issues with additional fields will require more scrolling than the same backlog without any additional fields displaying. As a result, Jira limits the number of additional fields to three. Any more information you need to view will require you to view the issue details.

A best practice to follow is to avoid adding free text fields in this section. If you chose to view the description as an additional field in your backlog view, then long description issues will take up your entire backlog screen, making it harder to prioritize your issues. Limit yourself to include fields with short values, such as dates or option fields to keep your board manageable yet clear.

Estimation Configuration (Scrum)

Only available for Scrum boards, estimation criteria can be configured to reflect how you want the burndown charts to be calculated for your board. Here is an example of what this configuration screen looks like:

By default, the Story Points field will track your estimates and drive your burndown charts and velocity metrics. However, you can choose another field to accomplish this purpose if you choose. Additionally, instead of calculating your burndown charts based on the Estimation Statistic, you can use Jira’s Time Tracking feature to have time drive those charts instead of story points.

Working Days Configuration

Configuring working days for your board determines whether or not non-working days should be included in your reports or dashboard gadgets. The default weekday work schedule (Monday through Friday) and automatic detection of your time zone usually suffice, but if your working hours differ, you can adjust your settings accordingly. Here is an example of what this configuration looks like:

Issue Detail View Configuration

When you click on an issue in your Jira board, a preview of that issue’s data will appear on the right side of the board:

The data displayed in this preview can be configured by a board administrator. Board administrators can choose which fields to show and hide in the preview, as well as change the order of appearance for fields within a certain type. If you remember our Jira 101 post on Issue Layouts, fields in Jira are grouped together by type. The same holds true for fields in the preview.

For example, all date fields can be added/removed and reordered – but the order will only be reflected within the Dates section. Configuring the data available in the preview can make your team more efficient – especially if they do not have to click twice to see a particular field for an issue. Here is an example of what the Issue Detail View Configuration screen looks like:

Configured Boards for Your Team

Boards are crucial artifacts in the Jira ecosystem and are where the bulk of your team’s work will occur. Thus, it is important as a board administrator to understand the available configurations that you can use to make your board more efficient, understandable, and reportable to your individuals interested in your project. 

In the next post, we’ll explain how project administrators can view information and make modifications to their Jira projects to increase their usefulness to their team. 

Make sure to check back in the following weeks for the rest of the Jira 201 series:

• Part 1 – Introduction into Jira Issue Configurations
• Part 2 – I Just Became a Jira Board Administrator, What Can I Do?
• Part 3 – I’m a New Jira Project Administrator, What Can I Do?
• Part 4 – Everything You Need to Know About Jira Workflows
• Part 5 – How to Set Up Your Jira Service Desk Project

Other recent posts: