It pairs issue tracking and project management, keeping everything in the same place, so that you don't need to jump between different platforms to organize your workflow.
With issue boards, you organize your issues in lists that correspond to their assigned labels, visualizing issues designed as cards throughout those lists.
You define your process, and GitLab organizes it for you. You add your labels then create the corresponding list to pull in your existing issues. When you're ready, you can drag and drop your issue cards from one step to the next.
Watch a video presentation of the Issue Board feature (introduced in GitLab 8.11 - August 2016).
Advanced features of issue boards
- Create multiple issue boards per project.
- Create multiple issue boards per group. (PREMIUM)
- Add lists for assignees and milestones. (PREMIUM)
Check all the GitLab Enterprise features for issue boards.
How it works
With issue boards you can have a different view of your issues while maintaining the same filtering and sorting abilities you see across the issue tracker. An issue board is based on its project's label structure, so it applies the same descriptive labels to indicate placement on the board, keeping consistency throughout the entire development lifecycle.
An issue board shows you what issues your team is working on, who is assigned to each, and where in the workflow those issues are.
You create issues, host code, perform reviews, build, test, and deploy from one single platform. Issue boards help you to visualize and manage the entire process in GitLab.
With multiple issue boards, you go even further, as you can not only keep yourself and your project organized from a broader perspective with one issue board per project, but also allow your team members to organize their own workflow by creating multiple issue boards within the same project.
You can tailor GitLab issue boards to your own preferred workflow. Here are some common use cases for issue boards.
Use cases for a single issue board
With the GitLab Workflow you can discuss proposals in issues, categorize them with labels, and from there, organize and prioritize them with issue boards.
For example, let's consider this simplified development workflow:
- You have a repository that hosts your application's codebase, and your team actively contributes code.
- Your backend team starts working on a new implementation, gathers feedback and approval, and passes it over to the frontend team.
- When frontend is complete, the new feature is deployed to a staging environment to be tested.
- When successful, it's deployed to production.
If you have the labels "backend", "frontend", "staging", and "production", and an issue board with a list for each, you can:
- Visualize the entire flow of implementations since the beginning of the development life cycle until deployed to production.
- Prioritize the issues in a list by moving them vertically.
- Move issues between lists to organize them according to the labels you've set.
- Add multiple issues to lists in the board by selecting one or more existing issues.
Use cases for multiple issue boards
With multiple issue boards, each team can have their own board to organize their workflow individually.
With multiple issue boards, each team has one board. Now you can move issues through each part of the process. For instance: To Do, Doing, and Done.
Organization of topics
Create lists to order issues by topic and quickly change them between topics or groups, such as between UX, Frontend, and Backend. The changes are reflected across boards, as changing lists updates the labels on each issue accordingly.
Advanced team handover
For example, suppose we have a UX team with an issue board that contains:
- To Do
When finished with something, they move the card to Frontend. The Frontend team's board looks like:
Cards finished by the UX team automatically appear in the Frontend column when they are ready for them.
NOTE: Note: For a broader use case, please see the blog post GitLab Workflow, an Overview. For a real use case example, you can read why Codepen decided to adopt issue boards to improve their workflow with multiple boards.
Create lists for each of your team members and quickly drag and drop issues onto each team member's list.
Issue board terminology
An issue board represents a unique view of your issues. It can have multiple lists with each list consisting of issues represented by cards.
A list is a column on the issue board that displays issues matching certain attributes. In addition to the default "Open" and "Closed" lists, each additional list shows issues matching your chosen label, assignee, or milestone. On the top of each list you can see the number of issues that belong to it. Types of lists include:
- Open (default): all open issues that do not belong to one of the other lists. Always appears as the leftmost list.
- Closed (default): all closed issues. Always appears as the rightmost list.
- Label list: all open issues for a label.
- Assignee list: all open issues assigned to a user.
- Milestone list: all open issues for a milestone.
A Card is a box on a list, and it represents an issue. You can drag cards from one list to another to change their label, assignee, or milestone. The information you can see on a card includes:
- Issue title
- Associated labels
- Issue number
Users with the Reporter and higher roles can use all the functionality of the Issue Board feature to create or delete lists and drag issues from one list to another.
GitLab Enterprise features for issue boards
GitLab issue boards are available on GitLab Core and GitLab.com Free tiers, but some advanced functionality is present in higher tiers only.
Summary of features per tier
Different issue board features are available in different GitLab tiers, as shown in the following table:
|Tier||Number of Project issue boards||Number of Group issue boards||Configurable issue boards||Assignee lists|
|Core / Free||Multiple||1||No||No|
|Starter / Bronze||Multiple||1||Yes||No|
|Premium / Silver||Multiple||Multiple||Yes||Yes|
|Ultimate / Gold||Multiple||Multiple||Yes||Yes|
Multiple issue boards
Multiple issue boards allow for more than one issue board for a given project or group. This is great for large projects with more than one team or in situations where a repository is used to host the code of multiple products.
Using the search box at the top of the menu, you can filter the listed boards.
When you have ten or more boards available, a Recent section is also shown in the menu, with shortcuts to your last four visited boards.
When you're revisiting an issue board in a project or group with multiple boards, GitLab automatically loads the last board you visited.
Create an issue board
To create a new issue board:
- Click the dropdown with the current board name in the upper left corner of the Issue Boards page.
- Click Create new board.
- Enter the new board's name and select its scope: milestone, labels, assignee, or weight.
Delete an issue board
To delete the currently active issue board:
- Click the dropdown with the current board name in the upper left corner of the Issue Boards page.
- Click Delete board.
- Click Delete to confirm.
Configurable issue boards (STARTER)
An issue board can be associated with a GitLab Milestone, Labels, Assignee and Weight which will automatically filter the Board issues according to these fields. This allows you to create unique boards according to your team's need.
You can define the scope of your board when creating it or by clicking the "Edit board" button. Once a milestone, assignee or weight is assigned to an issue board, you will no longer be able to filter through these in the search bar. In order to do that, you need to remove the desired scope (for example, milestone, assignee, or weight) from the issue board.
If you don't have editing permission in a board, you're still able to see the configuration by clicking View scope.
Click the button at the top right to toggle focus mode on and off. In focus mode, the navigation UI is hidden, allowing you to focus on issues in the board.
Sum of issue weights (STARTER)
The top of each list indicates the sum of issue weights for the issues that belong to that list. This is useful when using boards for capacity allocation, especially in combination with assignee lists.
Group issue boards (PREMIUM)
Accessible at the group navigation level, a group issue board offers the same features as a project-level board, but it can display issues from all projects in that group and its descendant subgroups. Similarly, you can only filter by group labels for these boards. When updating milestones and labels for an issue through the sidebar update mechanism, again only group-level objects are available.
Assignee lists (PREMIUM)
Like in a regular list that shows all issues with a chosen label, you can add an assignee list that shows all issues assigned to a user. You can have a board with both label lists and assignee lists. To add an assignee list:
- Click Add list.
- Select the Assignee list tab.
- Search and click the user you want to add as an assignee.
Now that the assignee list is added, you can assign or unassign issues to that user by dragging issues to and from an assignee list. To remove an assignee list, just as with a label list, click the trash icon.
Milestone lists (PREMIUM)
You're also able to create lists of a milestone. These are lists that filter issues by the assigned milestone, giving you more freedom and visibility on the issue board. To add a milestone list:
- Click Add list.
- Select the Milestone tab.
- Search and click the milestone.
Similar to the assignee lists, you're now able to drag issues to and from a milestone list to manipulate the milestone of the dragged issues. As in other list types, click the trash icon to remove a list.
Work In Progress limits (STARTER)
Introduced in GitLab 12.7
You can set a Work In Progress (WIP) limit for each issue list on an issue board. When a limit is set, the list's header shows the number of issues in the list and the soft limit of issues. You cannot set a WIP limit on the default lists (Open and Closed).
- You have a list with four issues, and a limit of five, the header will show 4/5. If you exceed the limit, the current number of issues is shown in red.
- You have a list with five issues with a limit of five. When you move another issue to that list, the list's header displays 6/5, with the six shown in red.
To set a WIP limit for a list:
- Navigate to a Project or Group board of which you're a member.
- Click the settings icon in a list's header.
- Next to Work In Progress Limit, click Edit.
- Enter the maximum number of issues.
- Press Enter to save.
Introduced in GitLab 12.8.
If an issue is blocked by another issue, an icon appears next to its title to indicate its blocked status.
Actions you can take on an issue board
- Create a new list.
- Delete an existing list.
- Add issues to a list.
- Remove an issue from a list.
- Filter issues that appear across your issue board.
- Create workflows.
- Drag issues between lists.
- Multi-select issue cards.
- Re-order issues in lists.
- Drag and reorder the lists.
- Change issue labels (by dragging an issue between lists).
- Close an issue (by dragging it to the Done list).
If you're not able to do some of the things above, make sure you have the right permissions.
First time using an issue board
The first time you open an issue board, you are presented with the default lists (Open and Closed) and a welcome message that gives you two options. You can either:
- Create a predefined set of labels (by default: To Do and Doing) and create their corresponding lists to the issue board.
- Opt-out and use your own lists.
If you choose to use and create the predefined lists, they will appear as empty because the labels associated to them will not exist up until that moment, which means the system has no way of populating them automatically. That's of course if the predefined labels don't already exist. If any of them does exist, the list will be created and filled with the issues that have that label.
Create a new list
Create a new list by clicking the Add list button in the upper right corner of the issue board.
Then, choose the label or user to create the list from. The new list will be inserted at the end of the lists, before Done. Moving and reordering lists is as easy as dragging them around.
To create a list for a label that doesn't yet exist, create the label by choosing Create new label. This creates the label immediately and adds it to the dropdown. You can now choose it to create a list.
Delete a list
To delete a list from the issue board, use the small trash icon present in the list's heading. A confirmation dialog will appear for you to confirm.
Deleting a list doesn't have any effect in issues and labels, it's just the list view that is removed. You can always add it back later if you need.
Add issues to a list
You can add issues to a list by clicking the Add issues button present in the upper right corner of the issue board. This will open up a modal window where you can see all the issues that do not belong to any list.
Select one or more issues by clicking the cards and then click Add issues to add them to the selected list. You can limit the issues you want to add to the list by filtering by author, assignee, milestone, and label.
Remove an issue from a list
Removing an issue from a list can be done by clicking the issue card and then clicking the Remove from board button in the sidebar. The respective label is removed.
You should be able to use the filters on top of your issue board to show only the results you want. This is similar to the filtering used in the issue tracker since the metadata from the issues and labels are re-used in the issue board.
You can filter by author, assignee, milestone, and label.
By reordering your lists, you can create workflows. As lists in issue boards are based on labels, it works out of the box with your existing issues. So if you've already labeled things with 'Backend' and 'Frontend', the issue appears in the lists as you create them. In addition, this means you can easily move something between lists by changing a label.
A typical workflow of using an issue board would be:
- You have created and prioritized labels so that you can easily categorize your issues.
- You have a bunch of issues (ideally labeled).
- You visit the issue board and start creating lists to create a workflow.
- You move issues around in lists so that your team knows who should be working on what issue.
- When the work by one team is done, the issue can be dragged to the next list so someone else can pick up.
- When the issue is finally resolved, the issue is moved to the Done list and gets automatically closed.
For instance you can create a list based on the label of 'Frontend' and one for 'Backend'. A designer can start working on an issue by adding it to the 'Frontend' list. That way, everyone knows that this issue is now being worked on by the designers. Then, once they're done, all they have to do is drag it over to the next list, 'Backend', where a backend developer can eventually pick it up. Once they’re done, they move it to Done, to close the issue.
This process can be seen clearly when visiting an issue since with every move to another list the label changes and a system not is recorded.
Drag issues between lists
When dragging issues between lists, different behavior occurs depending on the source list and the target list.
|To Open||To Closed||To label
|From Open||-||Issue closed||
|From Closed||Issue reopened||-||Issue reopened
Multi-select issue cards
Introduced in GitLab 12.4.
You can select multiple issue cards, then drag the group to another position within the list, or to another list. This makes it faster to reorder many issues at once.
To select and move multiple cards:
- Select each card with Ctrl+
Clickon Windows or Linux, or Cmd+
- Drag one of the selected cards to another position or list and all selected cards are moved.
Issue ordering in a list
When visiting a board, issues appear ordered in any list. You're able to change that order by dragging and dropping the issues. The changed order will be saved to the system so that anybody who visits the same board later will see the reordering, with some exceptions.
The first time a given issue appears in any board (that is, the first time a user loads a board containing that issue), it is ordered with respect to other issues in that list according to Priority order.
At that point, that issue is assigned a relative order value by the system representing its relative order with respect to the other issues in the list. Any time you drag-and-drop reorder that issue, its relative order value changes accordingly.
Also, any time that issue appears in any board when it's loaded by a user,
the updated relative order value is used for the ordering. (It's only the first
time an issue appears that it takes from the Priority order mentioned above.) This means that
A is drag-and-drop reordered to be above issue
B by any user in
a given board inside your GitLab instance, any time those two issues are subsequently
loaded in any board in the same instance (could be a different project board or a different group
board, for example), that ordering is maintained.
This ordering also affects issue lists. Changing the order in an issue board changes the ordering in an issue list, and vice versa.
A few things to remember:
- Moving an issue between lists removes the label from the list it came from and adds the label from the list it goes to.
- An issue can exist in multiple lists if it has more than one label.
- Lists are populated with issues automatically if the issues are labeled.
- Clicking the issue title inside a card takes you to that issue.
- Clicking a label inside a card quickly filters the entire issue board and show only the issues from all lists that have that label.
- For performance and visibility reasons, each list shows the first 20 issues by default. If you have more than 20 issues, start scrolling down and the next 20 appears.