Plan

GitLab helps teams organize, plan, align and track project work to ensure teams are working on the right things by maintaining end to end visibility and traceability of issues throughout the delivery lifecycle.

By using GitLab for the plan stage your, you use the same tool that developers use to create, test, secure, and release the software making the whole process transparent and adding more collaboration.

With GitLab Plan you can:

• decompose your work in items called “epics,” “issues,” and “tasks”,
• prioritize thoses items,
• assign them to devs or other team members,
• organize it into sprints / milestones
• racking the progress and visualize the workflow

Additionally, GitLab Plan integrates with other GitLab features , such as Merge Requests and CI/CD pipelines, ensuring that the planning components are seamlessly connected to the execution and deployment phases.

Ensuring transparency, improves communication among team members.

Organize Work

GitLab uses work items as a unified framework to represent all types of work across different organizational levels. Work items support hierarchical relationships and can be linked together to represent complex workflows.

GitLab provides several types of work items: Epics , Issues , and Tasks .

 graph TB
      subgraph Legend["Work Items Hierarchy"]
          direction TB
          Epic["🎯 <b>EPIC</b>"]
          NestedEpic["📦 <b>EPIC (nested)</b>"]
          Issue["📝 <b>ISSUE</b>"]
          Task["✓ <b>TASK</b>"]

          Epic --> NestedEpic
          NestedEpic --> Issue
          Issue --> Task
      end

      style Epic fill:#030F77,stroke:#4477aa,color:#fff,stroke-width:3px
      style NestedEpic fill:#041295,stroke:#4477aa,color:#fff,stroke-width:2px
      style Issue fill:#3642AA,stroke:#4477aa,color:#fff,stroke-width:2px
      style Task fill:#6871BF,stroke:#4477aa,color:#fff,stroke-width:2px

To categorize your work items with greater precision, utilize GitLab labels to add custom types or statuses.

Epics

Epics in GitLab help you manage larger strategic initiatives by grouping related issues across different projects and teams.

They provide a high-level view of your project’s progress and help organize work by theme or strategic objective.

For more information, see GitLab Epic documentation .

Issues

An issue is the fundamental planning object where the team documents the use case in the description, discusses the approach, estimates the size and effort using issue weight, assigns work, and tracks progress.

Issues are used for user stories, bugs, tasks, and any work that can be completed within a sprint. They can contain as little or as much definition as needed to accomplish the work.

Issues support various attributes to help organize and track work:

• Weight: Estimate effort or complexity (useful for capacity planning)
• Labels: Categorize and filter issues
• Milestones and Iterations: Associate with release or sprint
• Health Status: Track risk level (on track, needs attention, at risk)
• Assignees: Multiple team members can be assigned to an issue

An issue can be closed when all the work is complete. You can define a Definition of Done (DoD) in issue description templates to share a common understanding of what done means.

GitLab supports issue description templates to pre-populate issue fields and ensure consistency. See How to create a Description Template for more details.

GitLab also provides quick actions (slash commands) to efficiently update issues using inline commands like /assign, /label, /estimate, and many others directly in comments.

Status

GitLab provides a dedicated Status field on work items to indicate their current state in the workflow.

Unlike labels, Status is a built-in field designed specifically to track lifecycle progression.

Status makes it easy for teams to see what should be worked on next, what is in progress, and what has been completed.

Default statuses

GitLab provides five default statuses out of the box, each belonging to a category that determines whether the work item stays open or is automatically closed:

Custom statuses and lifecycles

Groups can define custom statuses to replace the defaults across all subgroups and projects.

Custom statuses are organized into lifecycles as a collections of statuses assigned to a work item type, managed at the top-level group level by Maintainers and Owners.

Each lifecycle defines three transition defaults:

• Default open status: applied when creating or reopening an item.
• Default closed status: applied when closing an item.
• Default duplicated status: applied when marking an item as a duplicate, moved, or promoted.

Status vs. labels

Status and labels serve different purposes and complement each other:

• Status expresses the lifecycle state of a work item using a controlled vocabulary, and directly drives whether the item is open or closed.
• Labels are flexible tags for dimensions like priority, team, component, or domain — they have no effect on open/closed state.

If you previously used scoped labels such as status::todo or status::in-progress for lifecycle state, the native Status field is now the recommended approach.

Issue Relationships

GitLab allows you to link issues together to represent dependencies and related work. This helps visualize connections between work items and manage blockers effectively.

Three types of relationships are supported:

• Related to: General association between issues that are connected but without dependencies
• Blocks: Indicates this issue prevents another issue from being completed
• Is blocked by: Shows this issue cannot progress until another issue is resolved

When an issue has blocking relationships, a special icon appears next to its title on issue boards and lists.

Issue relationships work across projects, allowing you to link issues from different repositories within your GitLab instance.

For more information, see GitLab Issue Relationships documentation .

Tasks

Tasks are small, actionable pieces of work that are part of an issue. They represent a technical breakdown of an issue into manageable steps, providing clear visibility into progress toward completing the issue.

Time Tracking

GitLab provides built-in time tracking to help teams estimate effort and record actual time spent on work items. This feature works across issues, epics, tasks, and merge requests.

Time tracking supports two main capabilities:

• Time Estimates: Set how long you expect work to take using the /estimate quick action (e.g., /estimate 3d 4h for 3 days and 4 hours)
• Time Spent: Record actual hours worked using the /spend quick action or through the UI (e.g., /spend 2h 30m)

GitLab uses standardized time units: months (160h), weeks (40h), days (8h), hours (60min), and minutes.

Time tracking data can be viewed directly on work items and aggregated in time tracking reports, helping teams track velocity, manage capacity, and improve estimation accuracy over time.

For more information, see GitLab Time Tracking documentation .

Labels in GitLab

Labels (also called tags) are used to categorize, prioritize, and manage work items such as issues, merge requests, and epics. They enable teams to quickly filter and organize work based on specific criteria.

GitLab supports two types of labels:

• Standard Labels: Simple tags for organizing work under common themes (e.g., , )

• Scoped Labels: Follow a key::value format where only one label from a particular scope can be applied at a time (e.g., , )

For more information, see GitLab Labels documentation .

Visualize planning

Epics Board

Epic Board in GitLab is a visual project management tool that provides an overview of epics within a group, organized using configurable lists (vertical columns).

It extends the functionality of issue boards to higher-level planning and tracking, making it ideal for managing multiple related features or large-scale initiatives.

Epic boards display epics in a Kanban-style format, allowing you to drag and drop epics between columns to reflect their status or stage in the workflow.

The board supports filtering by labels, assignees, or other criteria to focus on specific subsets of work.

For more information, see GitLab Epic Board documentation .

Issues Board

Issue boards provide a visual Kanban-style representation to plan, organize, and visualize workflow for issues within a project or group.

Issue boards display issues as cards organized in vertical columns (lists). Each column typically represents a stage in your workflow, and columns can be configured based on labels, assignees, milestones, or iterations.

An issue board shows you:

• Which issues your team is working on
• Who is assigned to each issue
• Where issues are in the workflow
• Work-in-progress limits per column (optional)

Issues can be dragged and dropped between lists to update their status or move them through the workflow.

Issue boards support swimlanes to group issues by their parent epic, and can be filtered to show specific subsets of work.

For examples of how to use issue boards for different workflows, see Scrum with GitLab .

For more information, see GitLab Issue Board documentation .

Iteration

Iterations in GitLab are time-boxed periods used to organize and track work. They are the GitLab equivalent of sprints in agile methodologies.

Iterations are created within an Iteration Cadence, which defines the recurring pattern for your iterations (for example, 2-week cycles). The cadence automatically generates individual iterations based on this pattern.

Iterations are configured at the group level and cascade down to all projects within that group. Issues can be assigned to a specific iteration to track work completion within that timeframe.

Iterations provide Burndown and Burnup Charts to visualize progress and track remaining work.

For more details on using Iterations in a Scrum workflow, see Scrum with GitLab .

Milestones

Milestones help you organize issues, merge requests, and epics around specific delivery targets or planning horizons, such as product releases, versions, or Program Increments.

Milestones can be created at either the project or group level and integrate seamlessly with other GitLab planning tools such as Issues, Boards, and Epics.

Milestones also provide Burndown and Burnup Charts to visually track progress over the milestone period.

Roadmap

The Roadmap provides a timeline view (Gantt chart style) to visualize and track the progress of epics and milestones over time within a group.

It displays start and end dates, hierarchical relationships between epics, and can be filtered by labels, milestones, or other criteria to focus on specific initiatives.

For more information, see GitLab Roadmap documentation .