GitLab Project Management: The 2025 Complete Guide to Agile Workflows, Boards, Epics, and Sprints

It’s Monday, your roadmap just shifted, two critical bugs landed, and leadership wants a status before lunch. Your developers are writing code, your PMs are triaging issues, and design wants clarity on what’s shipping this sprint. GitLab can be the one place that keeps everyone aligned—from planning to deployment—if you set it up the right way. In this definitive guide, we’ll show you how to use GitLab for project management like a pro: create issues that get the right info the first time, run Scrum or Kanban boards without chaos, plan sprints and milestones that track to outcomes, and connect it all to your delivery pipeline. We’ll also cover where a dedicated GitLab time tracking layer like Everhour fits in for budgeting, forecasting, and clean reporting—without turning your workspace into a surveillance tool.

What Is GitLab Project Management?

GitLab is a DevSecOps platform that brings planning, source code, CI/CD, security, and operations together. For project managers and cross-functional teams, the “planning” side is where the magic starts: issues, boards, milestones/iterations (sprints), epics, and roadmaps live in the same home as your code and pipelines. That single system of record eliminates the “where is this tracked?” problem. The benefit isn’t just less tool-switching; it’s traceability. You can move from an executive dashboard to a roadmap, to an epic, to a user story, to a merge request, and finally to the deployment that shipped the change.

🌟 Key GitLab planning components you’ll use

• Issues: Atomic units of work (bug, feature, chore).
• Labels and weights: Triage, categorize, and size work.
• Boards: Kanban/Scrum views for flow and sprint execution.

• Milestones and iterations: Time-boxed goals and sprints.

• Epics and roadmaps: Multi-project planning and portfolio views (availability depends on plan/edition—check GitLab’s documentation).

• Merge requests: Code changes linked to issues, with approvals and checks.
• Wikis/Pages: Documentation that ships with your repo.
• Service Desk: Optional email-to-issue intake for external stakeholders.

In the following sections, we’ll provide a quick GitLab tutorial to help you get started with project management on the platform.

---

---

Getting Started: From Workspace Setup to a Working Board

Follow this setup once per group or business line — you’ll reuse the structure forever.

🏗️ Model your work with groups and projects

• 📂 Create a top-level Group for your product or business unit.
• 🪢 Add child groups for services/domains (if large) or a single Project (if small).
• 👥 Define roles (Maintainer, Developer, Reporter, Guest) to reflect who plans, builds, and reads.

🏷️ Establish your taxonomy with labels and templates

• 🔖 Define label prefixes for clarity: type:bug, area:auth, priority:P1, team:web, status:blocked.
• 📝 Create issue templates (Bug, Feature, Tech Debt, Docs) with checklists and required fields.
• 📑 Add a merge request template with context, testing notes, risk/rollback, and related issues.

📋 Create your first board

• 🎯 Make a board filtered by your team labels (e.g., team:web).
• ➡️ Add workflow columns: To Do → In Progress → In Review → Ready for QA → Done.
• ⚖️ Optional: apply WIP limits to In Progress and Review for better flow.
• 👩‍💼 Save a second board filtered by another team or epic for leadership views.

⏱️ Define time boxes with milestones or iterations

• 📆 Scrum: create 1–2 week iterations (sprints) and link your board to the current sprint.
• ♾️ Kanban: use a “quarterly milestone” for outcomes or rely on flow metrics without time boxes.
• 📉 Use milestones/iterations to unlock burndown and progress tracking.

🔗 Wire up the delivery loop

• 🔒 Link issues to merge requests — use closing keywords in commits to auto-update issue status.
• 🧪 Add CI status to MRs so reviewers see test and security results immediately.
• 🌍 Create a deployment environment so issues can reference where the change shipped.

---

Clean Feature Map: What to Use and Why

Feature	What it does	Why it matters	When to use it
Issues	Tasks, bugs, user stories with assignee, labels, due dates	Standard intake and tracking	Every piece of work should be an issue
Labels	Categories like type, priority, team, area	Instant triage and board filtering	Keep a short, well-named set with prefixes
Weights/estimates	Relative sizing (e.g., 1–8)	Plan capacity and measure velocity	Sprint planning and forecasting
Boards	Visualize work by column and filter by labels	Transparency, flow, WIP control	Daily standups and team execution
Milestones/iterations	Time-boxed goals or sprints	Burndown, deadline clarity	Scrum sprints, release trains, quarterly goals
Epics/roadmap	Roll-up of multiple issues or projects	Portfolio alignment and Gantt-like view	Multi-team initiatives, long-running efforts
Merge requests	Code changes with review and checks	Quality gate connected to work	Code review tied to issue/definition of done
Wiki/Pages	In-repo docs and published sites	Knowledge where the work lives	Runbooks, onboarding, contributor guides
Service Desk	Email-to-issue intake	External feedback without granting access	Support, field sales requests, partners

---

Scrum or Kanban in Gitlab (And a Hybrid That Actually Works)

Scrum (time-boxed)

• Create an iteration for each sprint (for example, Sprint 25: Oct 7–Oct 18).
• Hold backlog refinement weekly; add weights and acceptance criteria.
• During sprint planning, drag issues into the sprint and check capacity (sum of weights) against historical velocity.
• Use your sprint board daily; keep WIP low and move cards left → right.
• Inspect and adapt with a burndown and a retro at the end of the sprint.

Kanban (flow-based)

• No sprints; use a single board with WIP limits to reduce multitasking.
• Filter by area or service to avoid noise.
• Track lead time (request → done) and cycle time (start → done).
• Reduce bottlenecks by adding another reviewer or test lane rather than starting more work.

Hybrid

• Keep continuous flow for interruptions (bugs, support) on a Kanban board.
• Run sprints for feature delivery; give them iterations/milestones.
• Hold a weekly “triage hour” to classify new issues into either flow or next-sprint candidates.

---

Step-by-Step: Running Your First Sprint in GitLab

✅ Create or refine your labels (type, priority, area, team).

📝 Add/refresh issue templates: Bug, Feature, Research — include a Definition of Done checklist.

📋 Groom the backlog: ensure the next 2–3 sprints’ worth of issues have clear outcomes, labels, and weights.

📆 Create an iteration (sprint) with defined start and end dates.

📊 Plan the sprint: add issues until weights ≈ team capacity (historical velocity or hours → story points).

🔄 During the sprint

• ⏰ Daily: hold 10–15 min standups in the board view, not in chat.
• 🛑 Mid-sprint: protect WIP; swarm to unblock rather than pulling new work.
• 📦 Keep MRs small, link them to issues, and merge behind feature flags if needed.

🏁 End of the sprint

• 📉 Review the burndown and completed work; document blockers.
• 💬 Hold a retro; choose 1–2 process improvements and track them as issues.
• ➡️ Roll over unfinished work intentionally — don’t drag everything by default.

---

Deep-Dive Features That Save You Time (And Headaches)

🩺 Issue health and triage

• Use scoped labels (priority::P1–P4, status::blocked/needs-design/needs-QA) for mutually exclusive categories.
• Add due dates only when there’s a real external deadline—don’t create calendar noise.
• Pin an Intake issue template so external or non-technical reporters don’t skip key fields.

⚡ Workflows and automation

• Quick actions in comments: /assign @user, /estimate 3h, /spend 45m, /label ~“priority::P2”, /close.
• Closing keywords in commits or MR descriptions auto-transition issues when code merges.
• Set up code owners so changes touch the right reviewers every time.

📊 Epics and roadmaps (portfolio views)

• Use epics to group issues across multiple repos or services.
• Add child epics for multi-quarter programs.
• Roadmap views help leadership track progress and upcoming milestones without asking for extra slides.

📚 Docs and knowledge

• Keep a docs/ folder or a GitLab Wiki with a simple sidebar.
• “Runbooks” for common incidents should live next to the code they support.
• Use Pages to publish public docs or an internal handbook if your plan allows.

📬 Service Desk and external intake

• Let partners or internal business units email a support address that automatically creates an issue.
• Auto-label these issues (source:external) to keep them visible and measurable.

🔒 Security and approvals

• Require approvals from code owners on high-risk paths (e.g., migrations, infra changes).
• Use pipeline checks (tests, security scanning) as required status checks before merging.
• Keep secrets in protected variables and restrict who can access production deploys.

---

Feature/Use-Case Comparison (Plain-English)

Use case	Turn on	Why it helps
Bug triage at scale	Issue templates + priority labels + a “Bugs” board	Standardized intake and a triage lane keep chaos out of your sprint
Cross-team initiative	Epics + roadmap + child issues in multiple projects	Aligns many teams without spreadsheets; leadership sees real progress
Release planning	Milestones per release + board filtered to the milestone	Clear scope, burndown, and progress to a date you can defend
Interrupt-driven ops	Kanban board + WIP limits + Service Desk	Flow metrics replace “feels busy”; blockers surface early
Design-engineering handshake	status::needs-design/ready-for-dev/needs-QA labels + swimlanes	Cuts handoff latency; everyone sees the next step
Compliance trail	MR approvals + CODEOWNERS + protected branches	Review evidence lives with the change for audits

---

How Everhour Fits (Time, Budget, and Reporting Without Friction)

GitLab includes lightweight time commands, but most teams outgrow basic logging when they need budgets, forecasts, and client-ready reports. That’s where Everhour’s time tracker slots in cleanly.

Where teams use it

• Estimates → actuals: Add an “Estimate (h)” field to your issue template. Track actuals in Everhour as work happens (via timers or quick entry).

• Budget guardrails: Create project budgets (fixed fee or hourly). Get alerts when a sprint or epic nears a threshold.
• Sprint reviews that speak finance: Roll up time by label (feature, bug, research) or by milestone/epic to show where the week went.
• Client billing: Mark billable vs internal; generate invoices with descriptions pulled from issue titles or MR summaries.
• Portfolio planning: Compare team capacity (from past Everhour reports) to upcoming sprint estimates to set realistic scope.

Two simple implementation patterns

A) You plan in GitLab, track time in Everhour

• Keep your issues and sprints in GitLab.
• Add an “Estimate (h)” field and a “Client/Cost Center” label.
• Use Everhour timers while working (or log time after).
• Share a weekly report grouped by milestone for stakeholders.

B) You plan across tools

• If your PMs live in Asana/ClickUp/Jira and engineers live in GitLab, Everhour integrates with the PM tool, so time stays aligned to tasks while developers link GitLab MRs for traceability.
• Use shared IDs (labels like client:Acme or sprint:2025-10) so reporting maps cleanly across systems.

---

Best Practices for Teams New to GitLab Project Management

• 🏷️ Keep labels tight: Too many labels become noise; use prefixes and archive unused ones quarterly.
• 🖥️ One screen to rule the day: Run daily standup from the board, not chat. Move cards; don’t just talk.
• ✅ Definition of Ready and Done: Put both checklists in your issue template so quality gates are explicit.
• ✂️ Make small MRs: If your MR is hard to review, it’s hard to ship. Split by behavior or component.
• 📊 Drive by data, not drama: For Scrum, track velocity and burndowns. For Kanban, track lead/cycle time and WIP.
• 🛡️ Protect focus: Enforce WIP limits; swarm blockers; don’t open new work when items are stuck.
• 🚦 Close the loop with CI/CD: A green pipeline should be the default; broken builds halt merges.
• 📚 Document once, reuse forever: Store decisions (ADR docs), runbooks, and onboarding in the repo.
• 🔍 Review the system, not the people: Sprint retros and quarterly ops reviews are for fixing workflows and interfaces, not blaming.

---

Troubleshooting Common Friction Points

“We have hundreds of issues; nobody knows what matters.”

Solution: Create a “Now/Next/Later” triage view using labels and saved board filters. Archive or close stale items monthly.

“Our sprints keep overflowing.”

Solution: Estimate consistently. Track completed points vs planned (velocity). Plan the next sprint at 80–90% of velocity, not 120%.

“Reviews take forever.”

Solution: CODEOWNERS and two-stage checklists (Author → Reviewer). Keep MRs under a size threshold (e.g., < 300 lines changed). Add a “Ready for Review” status to your board.

“PMs don’t see what shipped.”

Solution: Link issues to MRs; use closing keywords; include release notes in milestone descriptions; share a weekly “Done” filter.

“Stakeholders want Gantt charts.”

Solution: Use epics/roadmap for a timeline view. Keep it lightweight—epics are about sequence and dependencies, not perfectly precise dates.

---

FAQ: GitLab for Project Management

Is GitLab only for technical teams?

No. Non-engineering teams (marketing, ops, design) can manage campaigns or workflows with issues and boards. The learning curve is lower when you start with a simple board and a short issue template.

What’s the difference between milestones and iterations?

Both are time boxes. Iterations behave like sprints and can repeat on a cadence; milestones are general time goals you attach to issues. Many teams use iterations for Scrum and milestones for releases or quarters.

Can GitLab replace my roadmap tool?

For many teams, yes. Epics and roadmaps provide a portfolio view across projects. For complex portfolio management, you may still pair GitLab with a PPM tool.

How do I size work—hours or points?

Either works if you’re consistent. Many teams prefer points (relative). If finance needs hours, keep points for planning and track actuals in Everhour for reporting.

Can I migrate from Jira/Trello?

GitLab provides importers for common tools. Even after migrating, expect to iterate on your labels and templates for a few sprints.

Does GitLab do resource management?

Not in the classical “people calendars” sense. Most teams pair GitLab with light capacity planning (points per sprint) and use Everhour reports to understand true availability.

---

Final Thoughts

GitLab shines when you let planning, code, and delivery live together. Issues capture intent, boards drive the day, iterations/milestones anchor time, epics keep strategy visible, and merge requests deliver outcomes. Start small: a crisp label set, one healthy board, one sprint. Then layer in epics, roadmaps, CODEOWNERS, and CI/CD gates as your practice matures.

When you’re ready to turn effort into real budget visibility, add Everhour. Keep estimating in your issue templates, track actuals via its GitLab time tracking integration, and share clear Gitlab time tracking reports grouped by labels, milestones, or epics. That’s how you move from “busy” to predictably delivering the right work, on purpose—and with the numbers to prove it.

🔎 Check out what real users have to say about Everhour:

“We could easily assess work loads for each individual remote worker, assess what tasks took longer than anticipated, and most importantly see any discrepancies in the day to day tasks. It enabled task handling to become easier to manage.” [Georgia, Capterra]

“Everhour has made my life so much easier when it comes to tracking time and managing projects. The reporting capabilities are awesome. I can easily see where I am spending time and adjust if necessary.” [Daniel, G2]

“The reporting feature is so easy to use and can be configured any way we need. It’s much stronger than other tools we’ve used in the past. It also integrates so well with our project management software.” [G2]

---

---