The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Content last reviewed on 2024-01-10
Enable teams to effectively plan and execute work in a single application
As GitLab pursues its vision of replacing disparate DevSecOps toolchains with a single application, the Plan stage aspires to build robust planning tools that tie directly into the broader DevSecOps lifecycle. Our goal is to empower teams to continuously deliver customer and business value with the shortest possible cycle times.
The Plan Stage provides tools for teams to manage and optimize their work, track operational health and measure outcomes. As an end-to-end DevSecOps platform, GitLab is uniquely positioned to deliver a planning suite that enables business leaders to drive their vision and DevSecOps teams to deliver value while improving how they work. In addition, the unification of the DevSecOps process allows GitLab to interlink data across every stage of development, from ideation, to planning, implementation, deployment, and deliver value to customers.
The Plan Stage is made up of four groups supporting all major categories needed to plan work for DevOps organizations, including:
For more details about groups scope of work and team members that support it, visit our categories page.
Our vision is to build a Plan experience that aligns with our configuration principles. When you look across the Enterprise Agile Planning tool landscape, you'll find solutions with large customer bases that cover many methodologies and personas. Our competitors have built highly flexible solutions with many configuration options to accommodate the large array of use cases. Unfortunately, this makes these tools non-performant and challenging to administer, leading to customer dissatisfaction.
There are now countless solutions that aim to make planning tools that teams love. For example, tools like Notion, Monday.com, and Asana simplify configuration and focus on user experience. We will follow a similar approach, but our differentiation will be an experience geared toward enabling DevSecOps organizations to optimize their agile fluency.
As examples, GitLab will provide:
We have strong signals from our customers that they want a planning tool that supports their processes but is not overbearing. Recent conversations include:
To achieve this vision, we are creating a new framework that will be used to implement all existing planning items in GitLab and can be extended to allow more types in the future. The new work items framework is more flexible and scalable than the implementation we have today for Issues and Epics. Building a new framework that can house all existing planning items means that we will have greater consistency and feature parity between different types of planning items in the future. One downside of this approach is that it will require migrating existing planning items into something new, and our users will feel temporary discomfort from the change. Since we are building the work items framework to align with the future vision, our users may see differences and inconsistencies between Issues, Epics and other Work Item Types. For example, we have updated the label selector in work items to address feedback about the multi-level selection workflow in Issues being cumbersome. We believe the benefits of consolidating into a new framework built with the future in mind will be worth the temporary discomfort while it is under construction.
Ideally we will avoid any changes in legacy issue and epic, however when the need arises we will discuss and decide if we need to prioritize any work to address usability issues to continue meeting user expectations. All members of the quad will be involved in that discussion. We will move existing planning items to the new framework striving to impact the fewest users possible. For example, instead of migrating Issues or Epics, we introduced Tasks as the first work item type to validate the framework. We will continue to make usability improvements to the work items framework to ensure it meets user expectations. We are committed to minimizing the transition pain for our users and consolidating the experience for Epics, Issues, and Tasks into work items as quickly as possible, with a target of EOY FY24.
As an end-to-end DevSecOps platform, GitLab is uniquely positioned to deliver a planning suite that enables business leaders to drive their vision and empower their development teams to work efficiently. Our unification of the DevSecOps process allows us to interlink data across every stage of development, from initial analysis to planning, implementation, deployment, and monitoring. Today, few teams can answer how long their software projects take, and even fewer can answer how long each stage in the process takes. Without this information, most teams are flying blind on their estimates, using past experiences and best guesses to best calculate the time or level of effort that it will take to get from an idea to production. Engineering and product managers need to parse through information in multiple systems to know if problems will keep their teams from meeting their plans. The data is often hard to understand, so engineers' days are interrupted with requests for status updates. Executives rely on status reports that are created manually and often inaccurate. To fully solve this problem, DevSecOps data should be displayed so that it's easy to understand for users that are not developers.
As examples, GitLab will:
Managing issues across an organization can be a time-consuming and tedious endeavor. It's normal for organizations to have a large number of stale issues that require manual clean-up. Our focus will be to let automation do the lower value work like managing status changes and automating the movement of work items among workstations (queues) so the people doing the work can focus more on creating value and less on remembering the process. At GitLab, we dogfood our issue tracker and have implemented a considerable amount of automation to start down this direction. We will double down on this strategy, incorporate automation into our product and reduce the manual setup required to enable it. GitLab can also provide suggestions and nudges that reduce the number of actions required to complete common tasks.
GitLab has recently created AI-powered stage and the Plan Stage has been collabrating with that stage to bring new AI-powered Planning capabilities.
As examples, GitLab will provide:
In three years, the Plan Stage market will:
As a result, in three years, Gitlab will:
related, blocked by and blocking relationship types.Over the next year, we are focused on the following:
Plan offers functionality that ties into workflows in other stages. We are actively collaborating with other stages that are building upon Plan functionality to meet their users needs.
GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.
As a general rule of thumb, features will fall in the Core/Free tier when they meet one or more of the following criteria:
Some examples include:
As a general rule of thumb, features will fall in the Premium tier when they meet one or more of the following criteria:
Some examples include:
As a general rule of thumb, features will fall in the Ultimate tier when they meet one or more of the following criteria:
Some examples include:
An example of what the end result data model and pricing could look like based on these pricing principles:
