GitLab Roadmap: How to Set It Up, Plan a Quarter and Share It
7 min read ยท 2026-10-25
A GitLab roadmap is the timeline view of a group's epics and milestones, shown as bars across weeks, months or quarters. You open it from a group's left sidebar under Plan, then Roadmap. It is available on the Premium and Ultimate tiers, and an epic only appears on it once it has a start or due date.
This guide shows how to set it up so the view is actually useful: how to structure groups and epics, when to use fixed or inherited dates, which labels and milestones to add, and how to read progress. It then walks through one quarter as a 13-week plan with milestones, a filled-in example for a product team, who owns what, and how to present the roadmap to leadership without showing them hundreds of issues.
The roadmap at a glance
Goal: Your group has a GitLab roadmap that shows every quarterly initiative as an epic with dates, progress and health, and the team updates it weekly and reviews it at the end of the quarter. Duration: 13 weeks (one quarter)
Structure the group (Week 1)
Decide where epics live and how work rolls up.
- Pick the top-level group or subgroup that will hold the roadmap, usually one per product or product area.
- Agree on levels: a parent epic per initiative, child epics per feature, issues for the work.
- Create scoped labels for roadmap filters, such as theme::growth, theme::platform or team::payments.
- Agree on one label, such as roadmap, for epics that leadership should see.
Milestone: Group structure, epic levels and roadmap labels written down in the group wiki or README and agreed by product and engineering leads.
Create epics with dates (Weeks 1-2)
Put every initiative for the quarter on the timeline.
- Create one parent epic per initiative with a short outcome in the description, such as cut checkout drop-off.
- Set fixed dates on parent epics you have committed to, and inherited dates on child epics that should follow their issues.
- Add child epics for each feature and link existing issues to them.
- Apply theme, team and roadmap labels to each epic.
Milestone: Every initiative for the quarter appears on the roadmap with dates, labels and child items.
Plan milestones and issues (Weeks 2-3)
Connect the roadmap to delivery dates.
- Create milestones for releases or sprints with start and due dates.
- Assign issues to milestones so inherited epic dates reflect real delivery dates.
- Add weights to issues if your team estimates, so progress can be measured by weight.
- Mark dependencies between epics and issues with linked items.
Milestone: Most issues under roadmap epics have a milestone, and the roadmap's milestone row shows the release dates.
Configure and share the view (Week 3)
Give each audience a view that answers its questions.
- Open Plan, then Roadmap, and choose a date range (This quarter, This year or Within 3 years) and a layout.
- Turn on progress tracking and choose weight or issue count.
- Filter by the roadmap label for leadership and by team label for each squad.
- Bookmark each filtered view, since the settings are kept in the URL, and pin the links in your team channel.
Milestone: Bookmarked views for leadership and each team, shared in the team channel and the group README.
Run the quarter (Weeks 4-12)
Keep the roadmap true to what is happening.
- Update epic dates and descriptions in a weekly product and engineering sync.
- Set health status on parent epics (On track, Needs attention, At risk) if you are on Ultimate, or use scoped labels if you are not.
- Move or close epics when scope changes instead of letting dates drift.
- Post a short written update each month with the roadmap link and changes since last time.
Milestone: Every parent epic updated at least weekly, with no epic past its due date and still open without a note.
Review and plan next quarter (Week 13)
Learn from the quarter and set up the next one.
- Compare planned dates with actual close dates for each parent epic.
- Close finished epics and move unfinished work into next quarter's epics.
- Run a short retrospective on estimates, dependencies and scope changes.
- Create next quarter's parent epics with fixed dates and labels.
Milestone: Quarter review shared with stakeholders, and next quarter's epics on the roadmap before week 1 starts.
How the GitLab roadmap works
The roadmap is a group-level view. It shows the epics in that group and its subgroups as horizontal bars, plus an optional row of milestones. Epics with child epics can be expanded with the chevron next to their title, so you can show initiatives first and drill into features.
You can pick a date range preset: This quarter, This year or Within 3 years. Depending on the range, the timeline shows weeks, months or quarters. You can filter by author, label, milestone and other fields, sort by start date, due date, title or last update, and show open, closed or all epics. On Ultimate, a blocked icon appears on epics blocked by another epic.
- Where: group sidebar, Plan, then Roadmap.
- Tier: Premium and Ultimate.
- What shows: epics with a start or due date, and milestones if you turn them on.
- Progress: the bar shows completion by issue weight or issue count, set in the roadmap settings.
Fixed or inherited dates
Each epic's start and due dates can be fixed or inherited. A fixed date is one you type in. An inherited date is calculated from the epic's children: the earliest start and latest due date among child epics, issues and the milestones assigned to them. Inherited dates update as children change.
A common setup is fixed dates on parent epics (the commitment you made to stakeholders) and inherited dates on child epics (what the team is actually planning). When a child epic's inherited due date moves past the parent's fixed date, the gap is visible on the roadmap and you can discuss it before the deadline, not after.
Example: a quarter on a GitLab roadmap
Take a product team at a B2B SaaS company with three squads (checkout, onboarding and platform) in one GitLab group. The product director wants one roadmap for leadership and one view per squad.
Leadership sees five bars. Squads see their own epics with child items and issue progress. Both views come from the same epics, so there is only one version of the truth.
- Parent epic, owner checkout PM: Faster checkout, fixed dates for weeks 1-10, labels roadmap and team::checkout. Milestone: new payment step released in the 2.4 milestone.
- Parent epic, owner onboarding PM: Self-serve setup, fixed dates for weeks 2-12. Milestone: setup wizard live for all new accounts.
- Parent epic, owner platform lead: Single sign-on, fixed dates for weeks 1-8, inherited child dates. Milestone: SSO generally available.
- Parent epic, owner platform lead: Database upgrade, labeled theme::platform but not roadmap, so it stays off the leadership view.
- Parent epic, owner product director: Usage reporting discovery, fixed dates for weeks 6-13. Milestone: research findings shared with leadership.
Who owns what
The roadmap is only as good as the dates and descriptions on the epics. Assign a clear owner to each parent epic and make updating it part of that person's weekly routine.
Keep editing rights broad but responsibility narrow. Anyone can add issues, but only the epic owner changes the parent epic's fixed dates.
- Product director or head of product: the set of parent epics, labels and the leadership view.
- Product managers: parent epic dates, descriptions and health status for their area.
- Engineering managers: child epics, issue estimates and milestone assignments.
- Squad members: keep issues updated and linked to the right epic.
- Program or delivery manager: weekly sync, dependency tracking and the quarterly review.
How to present it to leadership
The roadmap view works well in a live walkthrough. Filter by your roadmap label, choose This quarter or the quarters layout under Within 3 years, collapse child epics, and turn milestones on. That gives leaders a short list of bars with progress and release dates.
For a board pack or a monthly update, build one slide that mirrors the view: one row per initiative with owner, target date, status and a one-line outcome. Leave out issue lists and technical detail. Add a short note for anything that moved since last month and why.
If you are on the Free tier
The roadmap view and epics are part of the Premium and Ultimate tiers. On the Free tier, teams often plan with milestones that have start and due dates, labels for themes, and issue boards grouped by milestone or label.
You can still run the same quarterly routine: one milestone per release, a label per initiative, a weekly sync and a written monthly update. If leadership needs a timeline picture, build it as a simple slide from the milestone dates.
Common mistakes to avoid
- Creating epics without dates leaves them off the timeline, so give every roadmap epic a start or due date.
- Showing every epic to leadership buries the message, so use a roadmap label and share a filtered view.
- Setting inherited dates on parent epics hides slipping commitments, so use fixed dates for commitments and inherited dates for child epics.
- Letting epic dates go stale makes the roadmap untrusted, so update them in a weekly sync.
- Assigning issues to no milestone makes inherited dates meaningless, so put roadmap issues in a milestone.
- Changing scope silently confuses stakeholders, so add a note to the epic and the monthly update when plans change.
Frequently asked questions
How do I create a roadmap in GitLab?
Create epics in a group and give each one a start or due date. Then open the group, go to Plan, then Roadmap. Use filters, date ranges and the milestone toggle to shape the view.
Is the GitLab roadmap available on the Free tier?
No. The roadmap view and epics are part of the Premium and Ultimate tiers. Free tier teams often plan with milestones, labels and issue boards instead.
Why is my epic not showing on the GitLab roadmap?
The most common reason is that it has no start or due date. Also check the filters, the open or closed setting and the date range. An epic outside the selected range will not show.
How is progress calculated on the GitLab roadmap?
The epic bar shows progress from its child issues. In the roadmap settings, you can turn progress tracking on or off and choose whether it uses issue weight or issue count.
Can I share a filtered GitLab roadmap view?
Yes. The roadmap settings and filters are kept in the URL, so you can bookmark a view and share the link. Viewers need access to the group to see it.