Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Product Direction - Product Planning

Product Planning


The Product Planning group aims to allow for organizations, business groups, and teams to be able to plan in a collaborative manner within the GitLab DevOps platform. In order to accomplish this, our group is focusing on creating a flexible and unified planning experience that teams and organizations of all sizes can successfully navigate and leverage.

Project Life-cycle


Successful projects begin with high level planning, perhaps a business need, or a contractual statement about what the project must accomplish. It is at this level that successful definitions of discrete goals should occur. There are many such ways to complete this, but at some level, jobs to be done and features need to be captured as a single source of truth.

We are in the process of advancing our Requirements Management functionality to ensure that the project definition can be captured and referenced for the life of the project.


Once the work has been defined, it's time to begin structuring the jobs to be done into logical pieces that can be allocated to teams or groups. Our Epics category allows you to manage your projects efficiently and with less effort by creating logical groups of issues that share a theme, across projects and milestones. To aid in planning, our Roadmaps category allows users to visually plan and map projects into a timeline view. This helps to clearly articulate sequencing and provides an easy method of collaboration with relevant stakeholders.


We recognize that projects are dynamic and that successful projects continue planning throughout the life-cycle of the project. The same epics and roadmaps used to decompose work at a business, portfolio, or project level also allow for successful planning at the sprint or milestone level. Our new epic swimlanes functionality will make this easier than ever, allowing teams to not only visualize issues on a board, but their parent epics.


A project cannot be considered complete until it successfully satisfies the defined goals. Whatever testing looks like in your organization, our advanced CI/CD pipelines, coupled with our emerging Quality Management functionality will allow for a simple and unified approach to verifying success.


The following categories fall within the Product Planning group. Listed below each category is a brief description and the upcoming functionality we're building to advance each category. For further information, check out the direction page for each individual category to dive deeper into our mission to strengthen the product planning capabilities of GitLab.

Requirements Management

Requirements Management Direction

Requirements Management aims to allow organizations of all sizes to successfully create and maintain a single source of truth with respect to the definition of a projects. This definition can take whatever form makes the most sense to an organization, be it formal requirements, or high level jobs to be done. Regardless of a projects complexity, GitLab strives to allow for a single source of truth that encourages collaboration among all relevant user personas, and allows for the defined success criteria to be at the center of your organizations DevOps solution.

Top Strategic Focus

Our initial strategic goal for requirements management is to allow it to replace external tooling for software development and test teams. Historically, it has always been cumbersome and time consuming to manually trace requirements implementation and test coverage using currently available tools. Our customers are excited to see an opportunity within GitLab to automate this traceability. Therefore, our top strategy item is to enable teams to bring their requirements into GitLab, implement and test these requirements, and export the requirements with the corresponding coverage data back to their external tools.

This has three significant benefits for organizations:

  1. Their teams can work in an agile continuous testing / delivery mindset, and have their requirements coverage information be collected for them. This raises the teams efficiency tremendously and effectively eliminates the manual steps of tracing requirements to code / test.

  2. Since the software teams no longer need to utilize expensive external tools, program costs can be reduced significantly.

  3. Systems teams can maintain their existing requirements tool chains for industry conformity and complex analysis (where these tools make sense).


Epics Direction

Epics allow you to manage your portfolio of projects more efficiently and with less effort by tracking groups of issues that share a theme, across projects and milestones. Nest multiple child epics under a parent epic to create deeper work structures that enable more flexible and granular planning.

What's Next for Epics
  1. Epic Swimlanes on Boards - MVC in 13.5
  2. Program/Epic Level Boards


Roadmaps Direction

Visually plan and map projects in a roadmap that can be used for tracking and communication. GitLab provides timeline-based roadmap visualizations to enable users plan from small time scales (e.g. 2-week sprints for development teams) to larger time scales (e.g. quarterly or annual strategic initiatives for entire departments).

What's Next for Roadmaps
  1. Better Filtering on Roadmaps
  2. Surface Dependencies on Roadmap

Quality Management

Quality Management Direction

Our goal for Quality management in GitLab is to allow for uses to track performance of test cases against their different environments over time, allowing for analysis of trends and identifying critical failures prior to releasing to production.

What's next for Quality Management

The first step in building out Quality Management is a scaffolding framework for testing. In particular, we are calling these test cases, and test sessions. These will be first class native objects in GitLab, used to track the quality process of testing itself.

The MVC can be seen at This work is currently ongoing, and we expect to have full support for test cases in GitLab 13.5, with additional support for test sessions in GitLab 13.6.

Service Desk

Service Desk

Service desk allows your organization the opportunity to provide an email address to your customers. These customers can send issues, feature requests, comments, and suggestions via email, with no external tools needed. These emails become issues right inside GitLab, potentially even in the same project where you are developing your product or service, pulling your customers directly into your DevOps process.

What's next for Service Desk
  1. Allow private comments on all commentable resources

The above plan can change at any moment and should not be taken as a hard commitment, though we do try to keep things generally stable. In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone or epic, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.

Product Planning operations

This section is designed to help us all collaborate more effectively, and to provide an overview of our planning strategy.

How to collaborate with us

We believe in a world where everyone can contribute. We value your contributions, so here are some ways to join in!

issues and epics!

Category Epics Issues
Epics epics issues
Roadmaps epics issues
Requirements Management epics issues
Quality Management epics issues
Service Desk epics issues

How we prioritize

Our team uses the standard GitLab prioritization framework for feature requests, enhancements, and bug fixes as described in the Prioritization section of the GitLab Handbook.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license