Feature Request: Workflow-based Progress Tracking for GitLab Roadmap

Release notes

Enable epic progress tracking in GitLab Roadmap based on workflow labels or custom statuses instead of only open/closed issue states.

Currently, progress tracking in GitLab Roadmap is based solely on open vs. closed issues or issue weights. This feature would allow configuring progress calculation based on specific labels corresponding to different workflow stages (e.g., "To Do", "In Progress", "Review", "Done"), providing a more accurate view of actual epic advancement.

With the introduction of custom statuses for issues (Epic #364 (closed)), it's now time to leverage this capability in Roadmap progress tracking, bridging the gap between granular workflow management and high-level epic visualization.

Problem to solve

As a Product Manager / Project Manager, I want to track the progress of my epics in the Roadmap based on actual workflow stages, so that I can have precise visibility on feature advancement beyond simple open/closed status.

Problem Context

Currently, GitLab Roadmap progress tracking has a significant limitation:

  • An issue is considered "incomplete" as long as it's open, even if it's in final review
  • A closed issue counts as "complete", even if it doesn't meet the team's "Done" criteria
  • Teams using detailed workflows (To Do → In Progress → Review → Testing → Done) cannot reflect this progression in the Roadmap

Concrete example: A team has 10 issues in an epic:

  • 2 issues are "To Do" (20%)
  • 3 issues are "In Progress" (30%)
  • 3 issues are "In Review" (30%)
  • 2 issues are "Done" and closed (20%)

Currently, the Roadmap displays 20% progress (2/10 closed), whereas actual progress could be considered 50-60% if we count issues in review as partially complete.

Alignment with GitLab's Evolution

GitLab has recently introduced custom statuses for work items (Epic #364 (closed)), allowing teams to define their own workflow stages beyond open/closed. However, this granular workflow information is not yet utilized in epic progress calculations. This creates a disconnect:

  • ✅ Teams can now define custom workflow statuses
  • ❌ But Roadmap progress tracking still uses the old binary open/closed model
  • ❌ The valuable workflow data captured through custom statuses remains unused for portfolio-level reporting

This feature request proposes to bridge this gap by making progress tracking workflow-aware.

Intended users

User experience goal

Users should be able to configure progress tracking calculation rules at the epic, group, or project level by selecting workflow labels or custom statuses and assigning them a completion percentage.

For example:

  • Label/Status "To Do" = 0% progress
  • Label/Status "In Progress" = 30% progress
  • Label/Status "In Review" = 70% progress
  • Label/Status "Done" (or closed issue) = 100% progress

Proposal

Proposed Solution

  1. Add Progress Tracking configuration option at Epic/Group/Project level:
    • Current options: "Issue count" or "Issue weight"
    • New option: "Workflow-based tracking"
  2. Workflow configuration interface:
    • Allow selection of existing labels OR custom statuses
    • Assign a completion percentage to each label/status (0-100%)
    • Define priority order if an issue has multiple labels
    • Leverage existing custom statuses (Epic #364 (closed)) when available
  3. Progress calculation:
    • For each issue in the epic, identify the active workflow label/status
    • Apply the corresponding percentage
    • Calculate weighted average (by weight if enabled, otherwise by count)
  4. Display in Roadmap:
    • Progress bar reflecting workflow-based calculation
    • Tooltip detailing distribution by workflow status
    • Ability to filter view by workflow status

User Journey

  1. A Product Manager accesses an epic's settings in the Roadmap
  2. They enable "Workflow-based progress tracking"
  3. They select their workflow labels (e.g., scoped labels status::*) OR use custom statuses
  4. They assign percentages: status::todo (0%), status::doing (40%), status::review (70%), status::done (100%)
  5. The Roadmap automatically recalculates progress
  6. The team can now track actual progress without having to prematurely close issues

Integration with Custom Statuses (Epic #364 (closed))

This feature would be the natural next step after custom statuses implementation:

  • When custom statuses are enabled on issues, use them as the default source for workflow stages
  • When custom statuses are not available, fall back to label-based workflow
  • Provide a unified progress tracking experience regardless of the underlying workflow mechanism

Further details

Use Cases

Use Case 1: Agile Team with Strict Definition of Done A team only closes issues after production deployment. With the current system, their Roadmap shows 0% while nothing is in prod, even though 80% of the work may be done.

Use Case 2: Complex Validation Workflow A team with code review → QA → UAT → Production wants to see progress at each stage, not just at the end.

Use Case 3: Stakeholder Reporting PMs want to show stakeholders that "70% of features are in active development" rather than "10% are completed".

Benefits

  • Increased visibility: Progress more faithful to field reality
  • Better planning: Delivery anticipation based on actual workflow
  • Flexibility: Adaptation to teams' varied methodologies
  • Motivation: Visualization of continuous progress rather than all-or-nothing
  • Compatibility: Works with GitLab's existing scoped labels and custom statuses

Compatibility with Existing Features

  • Could leverage existing scoped labels (e.g., status::*)
  • **Natural integration with **custom statuses already being rolled out
  • Optional feature: teams can continue using the current system

Related Work

This feature request builds upon and complements:

  • Issue #8865 (closed) - Epic status or approval: While that issue focuses on epic-level status, this proposal focuses on calculating epic progress based on child issue statuses
  • Epic #364 (closed) - Improved Work Item lifecycle management: This proposal would leverage the custom statuses infrastructure to enhance Roadmap progress tracking
  • Issue #32876 (closed) - Weight and progress information in roadmap: Already implemented, but mentioned "Allow users to choose which metric to measure progress" as future scope

Permissions and Security

Permissions should follow the existing epic configuration model:

  • Guest (10) members: Can view configured progress tracking but cannot modify it
  • Reporter (20) members: Can view configured progress tracking but cannot modify it
  • Developer (30) members: Can view and potentially suggest configurations
  • Maintainer (40) members: Can configure workflow-based progress tracking at project level
  • Owner (50) members: Can configure workflow-based progress tracking at all levels

Security considerations:

  • Configuration must be versioned and auditable
  • Configuration changes should not retroactively alter history
  • Users without permissions on an epic should not see progress details

Documentation

Availability & Testing

Risks and Quality

  • Performance risk: Calculation will need to query labels/statuses of potentially thousands of issues
  • UX complexity risk: Configuration interface must remain simple
  • Confusion risk: Two calculation methods (old + new) may create ambiguity

Required Test Coverage

Unit tests:

  • Tests for progress calculation with different label/status configurations
  • Tests for priority rules when multiple labels are present
  • Tests for edge cases (missing labels, invalid percentages)
  • Tests for custom status integration

Integration tests:

  • API tests for creating/modifying configuration
  • Tests for impact on Roadmap queries
  • Migration tests for existing epics
  • Tests for custom status → progress calculation flow

End-to-end tests:

  • Tests for complete workflow: configuration → label modification → progress update
  • Tests for display in different views (Roadmap, Epic board, etc.)
  • Cross-browser tests for configuration interface
  • Tests for both label-based and custom status-based workflows

Available Tier

Proposal: Premium or Ultimate

Justification:

  • Roadmap is already a Premium+ feature
  • This feature targets mature teams with structured processes
  • Alignment with other advanced project management features
  • Custom statuses are Premium+ features, so this enhancement should follow the same tier

Feature Usage Metrics

Success Metrics

  1. Adoption:
    • Number of epics configured with workflow-based tracking
    • Percentage of groups/projects using the feature
    • Retention rate after 30 days
    • Adoption rate among custom status users
  2. Engagement:
    • Frequency of Roadmap consultation after activation
    • Number of configuration modifications per team
    • Time spent on Roadmap view
  3. Impact:
    • Correlation with better delivery predictability
    • Qualitative feedback from Product Managers
    • Reduction in "where are we?" questions in teams

Technical Instrumentation

  • Event: workflow_progress_tracking_enabled
  • Event: workflow_progress_configuration_updated
  • Event: roadmap_viewed_with_workflow_tracking
  • Event: custom_status_used_in_progress_tracking
  • Metric: percentage_epics_using_workflow_tracking
  • Metric: percentage_workflow_tracking_using_custom_statuses

What is the type of buyer?

Buyer Persona: Director of Engineering / VP of Product

This feature targets organizations seeking to improve their project visibility and governance, typically in enterprise contexts with multiple teams.

Suggested Tier: Premium (with Ultimate for advanced multi-level configurations)

Is this a cross-stage feature?

Yes, this feature could impact multiple groups:

  • Plan Group (primary owner): Roadmap, Epics, Issues
  • Project Management: Issue Boards, Labels, Workflows, Custom Statuses
  • Monitor Group: Potentially for analytics and reporting

PMs to include:

  • PM of Plan Group (primary owner)
  • PM of Project Management features (custom statuses owner)
  • PM of Value Stream Analytics (for future integration)

What is the competitive advantage or differentiation for this feature?

Competitive Advantage

Differentiation from competitors:

  • Jira: Requires paid plugins for such granular tracking
  • Azure DevOps: Less flexible on progress calculation customization
  • Asana: No workflow notion in progress calculation

GitLab Added Value:

  • Naturally integrates with existing scoped labels AND new custom statuses
  • Unifies workflow management and reporting in a single tool
  • No need for external portfolio management tool
  • Consistent with GitLab's end-to-end DevOps vision
  • Leverages recently introduced custom statuses, making GitLab the first platform to connect granular workflow stages to portfolio-level progress tracking

This feature would strengthen GitLab's position as a complete project management platform for mature teams, reducing the need for third-party tools like Jira or Monday.

Links / references

Related Issues and Epics

  • Epic #364 (closed) - Improved Work Item lifecycle management & native automations: &364
    • This proposal leverages custom statuses to enhance Roadmap progress tracking
  • Issue #8865 (closed) - Epic status or approval: #8865 (closed)
    • Related concept but focused on epic-level status rather than progress calculation
  • Issue #32876 (closed) - Weight and progress information in roadmap: #32876 (closed)
    • Mentioned "Allow users to choose which metric to measure progress" as future scope

Documentation

Label reminders 

/label ~"group::project management" ~"section::dev" ~"Category:Roadmaps" ~"Category:Epics"
/label ~"GitLab Premium" 
/label ~"type::feature" ~"feature::addition"
/label ~"workflow::problem validation"
/label ~"customer"
/label ~"custom statuses"

Note: This feature request is submitted by a GitLab user seeking to improve visibility of actual project progress in the Roadmap by leveraging workflow stages (via labels or custom statuses) rather than relying solely on open/closed issue status. With custom statuses now available for issues, this is the natural evolution to make Roadmap progress tracking workflow-aware.

Edited by 🤖 GitLab Bot 🤖