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.
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 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.
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.
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).
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 identifiying critical failures prior to releasing to production.
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 https://gitlab.com/groups/gitlab-org/-/epics/3852. 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 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.
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.