Columns represent the statuses an issue can be in. On a simple board, as shown in the following screenshot, we have three columns, and they are each mapped to an issue status:
- To Do: Issues that are waiting in queue to be worked on are mapped to the To Do workflow status
- In Progress: Issues that are currently being worked on are mapped to the In Progress workflow status
- Done: Issues that are completed are mapped to the
Doneworkflow status:
This is a very simple setup where issues only have three steps from start to finish. Often, you will have an existing workflow that is more complex than this.
Before we get into customizing columns, we first need to take a quick look at workflows in relation to JIRA Agile. As you may already know, JIRA uses workflows to move an issue from one status to the next. JIRA Agile also leverages this feature by mapping its columns to workflow statuses.
Since workflows in JIRA can often get very complicated, it sometimes makes it difficult to use the traditional JIRA workflows in an agile environment, so JIRA Agile introduced what is known as Agile Simplified Workflow.
Agile Simplified Workflow refers to workflows that are managed directly from within JIRA Agile, and are simplified and streamlined for agile usage. This allows you to:
- Maintain your workflow from your agile board, managed as board columns
- Move issues freely from one status (column) to another without restrictions from workflow conditions and validators
- Not have intermediate screens when you move issues between statuses, making it much easier to move cards (issues) on your boards
- Automatically set resolution values (as per your definition) when issues are moved to appropriate statuses (columns)
If you have created your agile board by using the built-in agile templates, then you are most likely using Agile Simplified Workflow.
If you are the board administrator, you can customize the board's columns to better reflect your workflow:
- Navigate to the Scrum board that you want to customize.
- Click on the Board drop-down menu and select the Configure option.
- Select Columns from the left navigation.
From the Column management page, you can customize the following options:
- Columns: You can add, remove, and rename columns.
- Column Layout: You can rearrange the order of columns.
- Issue Status Mapping: You can map columns to issue statuses. For each column, you can have one or more issue statuses mapped to it.
- Column Constraint: You can add constraints to columns, limiting how many issues can be in a status at any given time.
Let's start with creating new columns. There are two ways new columns can be created and mapped to issue statuses, depending on whether you are using Agile Simplified Workflow or not. You can determine if you are using the simplified workflow by looking at the Simplified Workflow field, and seeing if it says Using Agile Simplified Workflow, as shown in the following screenshot:
For a new column to be usable, it needs to have at least one status mapped. If you are using Agile Simplified Workflow, this is a very straightforward process. The Agile Simplified Workflow takes care of this for you, so you don't have to worry about manual column status mapping. It is recommended to use Agile Simplified Workflow where possible. To add a new column, perform the following steps:
- Click on the Add column button. A new column will be added to the list in the second-last position.
- Enter a name for the new column. A new issue status will also be created with the same name, and mapped to the new column.
If you are not using the Agile Simplified Workflow, you will need to perform the following steps:
- Create the new column as outlined in the preceding list.
- Create new workflow statuses to be mapped to the new column, and add the statuses used by the workflow.
- Manually drag and drop the statuses into the new column, as shown in the following screenshot:
You can also map additional statuses to columns by dragging the status you want to map from under the Unmapped Statuses section, and dropping them into the target column. Once you have mapped at least one status to the new column, it will be displayed on the board in active sprint mode.
It is recommended to have one column per workflow status to keep the flow logical and simple. However, you can have multiple statuses mapped to one column, as shown in the preceding screenshot, we have both Done and Fixed statuses mapped to the Done column. You will usually find the need to do this if you are creating a Scrum board for an existing project with a workflow in place, or you have a complex workflow that cannot be mapped to columns on the board one-to-one.
When you map multiple statuses to a column, such as the Done column in our example, and move an issue into the column, you will be able to select the appropriate status, as shown in the following screenshot:
When using Agile Simplified Workflow, you will see a checkbox option called Set resolution in the mapped workflow status. If you check this option, when an issue is moved into the corresponding column, it will be automatically assigned the resolution value of Done. JIRA Agile makes use of resolution value to determine if an issue has been completed, so it is important to assign a value for the status/column that represents the end of the workflow.
Once you have created all your new columns and mapped them to workflow statuses, you can re-arrange the column layout by dragging and dropping the columns left and right to their desired locations, as shown in the following screenshot. The order of your column should reflect your workflow, starting from the left and moving right, so it visually represents the logical flow of an issue through the work process:
As we will see in Chapter 5, JIRA Agile – Advanced, you will be able to export your issues from your board onto a physical board and import them back in, as long as the column layout of your JIRA Agile board is the same as your physical board.
JIRA Agile lets you specify constraints for your columns, to limit the number of issues that can be in a column at any given time. For example, you can set a constraint that there should be a minimum of three and no more than five issues in the In Progress column, as shown in the following screenshot:
Setting column constraints is not a normal practice for pure Scrum; it is used most commonly in Kanban; refer to Chapter 4, JIRA Agile for Kanban. However, people have found that some of the benefits of Kanban, such as using column constraints to identify problems in the workflow and improve the process, results in what is called Scrum-ban. To set up column constraints:
- Select how you would like to count the number of issues in the Column Constraint field.
- Enter the minimum and/or maximum values for the column you want to place a constraint on. You can have either a minimum or maximum, or both.
Once you have placed constraints on a column, if it is violated, the column will be highlighted. As shown in the following screenshot, the In Progress column has a maximum constraint of four issues, but we have five, so it is highlighted in red. The In Review column has a minimum constraint of two issues, but we have one, so it is highlighted in yellow:
Column constraints do not prevent you from violating the limits. They simply help to flag areas where there might be a problem. Setting the limits for your columns can be tricky, especially when you are just getting started. You should start with your "gut feeling" and run a few sprints, and refine the limits as you and your team get a better feel for the workflow. One way to get started is to base your limits on the number of people you have on your team. For example, if you have five developers, then your maximum limit for your In Progress columns (assuming it means development) should be no more than five, as it is not logical to have five people working on six issues at the same time.
So, if we look at the example in the preceding screenshot, we are over the maximum limit for the In Progress column. This could mean that the team, especially the developers, has overcommitted on their tasks; someone might have decided to work on two tasks in parallel. This is causing a bottleneck and issues are not being completed quick enough to move to the In Review column, causing a minimum limit violation, where you have reviewers waiting around for work. This data can be very useful in your sprint retrospective meetings, to review the problem and refine the process.
So as you can see, setting column constraints is situational and is based on your team's composition, as well as their abilities. As things change, you will need to change your limits accordingly. Remember, the goal here is to measure, identify, and improve.