The quad members (UX/Design, Quality, Product Management, Development) utilizing this process should focus on:
As long as the quad achieves these goals, they are encouraged to apply the process as appropriate based any unique characteristics of their group and also tailor the process based on how the team prefers to operate.
To support GitLab's long-term product health and stability while keeping the pace of new features for users, teams are asked to plan their milestones with an appropriate ratio of type::feature
, type::maintenance
, and type:bug
work. When labeling if the label selection for an issue or merge request isn't obvious, don't spend more than 60 seconds to decide and make a best effort to choose the most appropriate label.
If one of these labels clearly doesn't apply for an issue, consider using the type::ignore
label. This will exclude the issue from automation and dashboards used to do cross-functional prioritization and metrics tracking for the product. It is highly important we have accurate data, so please only use this label if the issue clearly does not pertain directly to Engineering changes to the product itself. This label will typically apply to issues used for planning or to track a process. For example, you could use the type::ignore
label for a milestone planning issue where the issue's purpose is organization and will not have MRs directly associated with it.
A team's ratio might change over time and different teams may have different ratios. Factors that influence what ratio is appropriate for a given team include the product category maturity, the area of the product they are working in, and the evolving needs of GitLab the business. Teams should review labeling for accuracy and minimize the number of type::undefined
items. This allows us to review the plans at the group, section, and company level with team members to ensure we appropriately prioritize based on cross-functional perspectives.
For more details on these three work types, please see the section on work type classification. The development EM is the DRI to ensure that the merge requests are accurateliy labeled.
Our backlog should be prioritized on an ongoing basis. Prioritization will be done via quad planning (collaboration between product, development, quality, UX) with PM as the DRI for the milestone plan. PMs, EMs, Quality, and UX will provide the following:
type::feature
issuestype::maintenance
issuestype::bug
issues using the bug prioritization dashboardNote: UX-related work items would be prioritized in accordance with the appropriate sub-types. UX related bugs are included in the automated process (S1/2 and so on), UX-related maintenance items will be included in the EM's prioritized list, Product (feature) UX items will have been included as part of our normal Product Development Flow.
The DRIs of these three core areas will work collaboratively to ensure the overall prioritization of the backlog is in alignment with section direction or any other necessary product and business needs. If a team is not assigned a Product Designer then there is no UX counterpart needed for prioritization purposes. PMs will prioritize the final plan for a given milestone.
The Product Manager is responsible for planning each milestone. Product Managers are also responsible for ensuring that their team's target ratios are maintained over time.
Add the milestone
(example) to review the milestone plan. The board will show the number of issues and cumulative issue weights for type::feature
, type::maintenance
, and type::bug
issues.
Cross-functional reviews will be done at the group, stage/section, and company level.
When the data is up-to-date and accurate. See the timeline
Review the dashboard filtered for the review scope (group, section, etc).
Context:
Maintenance/quality:
Features:
Trends:
The review collaboration can be done in a way that's most effective for the group, either synchronously (e.g. scheduled recurring call) or asynchronously (e.g. such as in retrospective issues).
Required collaborators from the quad for the group are:
The managers of the required collaborators should be included as optional participants.
The stage/section review is coordinated by each direct report of the VP of Development.
Required collaborators from the quad for the stage/section are:
Optional collaborators who should be invited but not required to participate:
The collaboration should be async first but include an optional sync review amongst stakeholders.
The name of the meeting and associated agenda document should be clearly defined so that the invitees can decide if they should attend.
The company-wide review is coordinated by the VP of Development.
Required collaborators from the quad for the stage/section are:
Optional collaborators who should be invited but not required to participate: