Plan Sprints and Releases with GitLab Issue Boards (2026)

GitLab Issue Boards are a surprisingly flexible tool for planning sprints and releases, often overlooked as just a Kanban board.

Let’s see one in action. Imagine a team working on a new feature. They’ve broken it down into several smaller tasks:

Epic: "User Profile Redesign"
Issues:
- "Design new profile layout" (Status: To Do)
- "Implement frontend for profile page" (Status: To Do)
- "Develop backend API for profile data" (Status: To Do)
- "Write unit tests for profile backend" (Status: To Do)
- "Conduct user acceptance testing for profile" (Status: To Do)

On their GitLab Issue Board, these issues appear in the "To Do" column.

# GitLab Issue Board Example

## Columns:

**To Do** | **Doing** | **In Review** | **Done**
------- | -------- | ----------- | --------
![Issue 1](https://example.com/issue1.png) | ![Issue 2](https://example.com/issue2.png) | ![Issue 3](https://example.com/issue3.png) | ![Issue 4](https://example.com/issue4.png)

Issue 1: Design new profile layout Issue 2: Implement frontend for profile page Issue 3: Develop backend API for profile data Issue 4: Write unit tests for profile backend

When a developer starts working on "Implement frontend for profile page," they drag it to the "Doing" column. Once a merge request is created and assigned for review, it moves to "In Review." After approval and merging, it lands in "Done."

The real power comes from how you structure these boards and issues. You can create multiple boards for different purposes. A common pattern is a "Sprint Board" and a "Release Board."

Sprint Planning:

A "Sprint Board" is typically scoped to a specific iteration, often a week or two. You can filter issues on this board using labels like sprint-1, sprint-2, or specific dates like 2023-10-26.

Create a new board: Navigate to your project’s "Issues" -> "Boards." Click "New board." Name it "Sprint 1 Board."
Filter by sprint label: In the board settings, under "List configuration," add a filter for sprint-1.
Visualize sprint scope: Now, this board only shows issues with the sprint-1 label. You can drag and drop these issues between columns like "To Do," "Doing," "Review," and "Done" to track progress within that sprint.
Assign issues: During sprint planning, you’d drag issues from a larger backlog (perhaps on a default board) onto the "Sprint 1 Board" and assign them the sprint-1 label.

Release Planning:

A "Release Board" focuses on the larger, overarching goals of a specific release. This board might not be tied to a strict timebox but rather to a version number, e.g., v2.0.

Create another board: Name it "Release v2.0 Board."
Filter by release label: Filter this board using a label like release-v2.0.
Track release features: All issues tagged with release-v2.0 will appear here. You can create custom columns to represent stages of a release, such as "Ready for Release," "In Testing," "Staging," and "Released."
Dependency visualization: Crucially, you can use related issues (linked issues) to build out release plans. If "Implement frontend for profile page" depends on "Design new profile layout," you can link them. On the board, this dependency isn’t explicitly drawn, but when you look at the issue details, you see the links. This helps ensure critical path items are addressed.

The underlying mechanism is GitLab’s robust issue tracking system. Boards are simply different views, filtered and organized by labels and milestones. Milestones are particularly useful for marking the target release version for a set of issues. You can assign issues to a milestone, and then filter your "Release Board" by that milestone.

A common pitfall is trying to manage too many things on one board. Separating sprint and release planning into distinct boards, each with its own filtering (via labels or milestones), keeps things manageable and provides clear visibility for different stakeholders.

When you’re using milestone-based filtering on a Release Board, and an issue is assigned to a milestone like v2.0, GitLab automatically shows issues in the board that belong to that milestone. The "Released" column can be populated by issues that have a release tag applied to them, or by manually moving issues into a "Done" state within that board, signifying they are part of the released version.

The most powerful way to manage dependencies across boards is by linking issues. If an issue on your "Sprint 1 Board" is blocked by another issue not yet ready, you can link them. This doesn’t automatically move issues between boards, but the link is visible in the issue sidebar, providing context.

The next logical step is to explore automating board transitions using GitLab CI/CD or webhooks, especially for moving issues to "Done" based on successful deployments.