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-09-20
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. The unification of the DevSecOps process allows GitLab to interlink data across every stage of development, from ideation to value delivered 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.
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 July 2024.
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 customization 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. Embracing a comparable philosophy, our approach will distinguish itself through a tailored experience driven by our platform strategy. Our focus is empowering DevSecOps organizations to enhance their agile fluency by seamlessly integrating workflows throughout the DevSecOps lifecycle.
We have heard the feedback that, while we should stay true to our principle of convention over configuration, GitLab should enable configuration options that allow organizations to accurately represent their way of working. Introducing additional configuration options will also allow us to create an experience that works by default, instead of heavily relying on label configuration. To address this feedback, we plan to introduce the features below:
GitLab will continue to put the user at the forefront, while further enabling organizations to satisfy their planning requirements through:
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:
Real-time boards (17.1) - Changes you make in the sidebar will instantly appear on the board itself, no more refreshing required. This reactive boards experience streamlines your workflow, allowing you to quickly make updates while seeing them reflected in real-time.
Over the next year, we are focused on the following:
Mature Value Streams Dashboard for Executives to enable decision-makers to identify trends, patterns, and opportunities for digital transformation improvements.In the next 1-3 milestones, we will focus on the following:
Executive-level summary of key metrics related to software performance and flow of value across the organization. These views will visualize the highest level of data about health of the software organization, and the DORA Performers score top to bottom. Adding "Usage overview" panel, to help the executive understand how the team is utilizing the platform.
Adding VSD Scheduled Reports as a CI/CD component - tool which allows you to periodically schedule a report with the most recent metrics from the Value Streams Dashboard feature. This will help decision-makers to focus on analyzing insights rather than spending time looking for the right dashboard with the relevant data.
Customizable widgets to show data that is relevant to user's goals and needs. Adding the "Product Analytics section" customizable UI capabilities. Integrate the Value streams dashboard page into the product analytics schema driven UI.
Enhanced VSA stage time investigation to help users quickly understand what has happened in the specific stage by visualizing the performance of the stage with the context of the work item (issues or MRs).
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.
Our pricing strategy is derived from GitLab's buyer based pricing model, with Free aligning to individuals, Premium to teams and Ultimate to organizations.
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: