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

Plan Stage

Plan

Plan teams:

The responsibilities of this collective team are described by the Plan stage. Among other things, this means working on GitLab's functionality around issues, issue boards, milestones, todos, issue lists and filtering, roadmaps, time tracking, requirements management, and notifications.

In GitLab issues, questions should start by @ mentioning the Product Manager for the corresponding Plan stage group. GitLab team-members can also use #g_plan.

For UX questions, @ mention the Product Designers on the Plan stage. Currently that is Alexis Ginsberg and Annabel Dunstone Gray.

How we work

Workflow

We work in a continuous Kanban manner while still aligning with Milestones and GitLab's Product Development Flow.

Issues

Issues have the following lifecycle. The colored circles above each workflow stage represents the emphasis we place on collaborating across the entire lifecycle of an issue; and that disciplines will naturally have differing levels of effort required dependent upon where the issue is in the process. If you have suggestions for improving this illustration, you can leave comments directly on the whimsical diagram.

plan-workflow-example.png

Epics

If an issue is > 3 weight, consider promoting it to an epic (quick action) and split it up into multiple issues. It's helpful to add a task list with each task representing a vertical feature slice (MVC) on the newly promoted Epic. This enables us to practice "Just In Time Planning" by creating new issues from the task list as there is space downstream for implementation. When creating new vertical feature slices from an epic, please remember to add the appropriate labels - devops::plan, group::*, Category:* or feature label, and the appropriate workflow stage label - and attach all of the stories that represent the larger epic. This will help capture the larger effort on the roadmap and make it easier to schedule.

Roadmap Organization

graph TD; A["devops::plan"] --> B["group::*"]; B --> C["Category:*"]; B --> D["non-category feature"]; C --> E["maturity::minimal"]; C --> F["maturity::viable"]; C --> G["maturity::complete"]; C --> H["maturity::lovable"]; E--> I["Iterative Epic(s)"]; F--> I; G --> I; H --> I; D --> I; I--> J["Issues"];

Board grooming

We perform many board grooming tasks asynchronously, using GitLab issues in the Plan project. The policies for these issues are defined in triage-ops/policies/plan-stage. Some of these issues use supplemental boards:

  1. Plan backend / frontend check: engineering managers check that issues on the current milestone have ~backend and ~frontend labels correctly assigned. If they don't, they won't show up on a team's build board.
  2. Plan group check: engineering managers check that issues on the current milestone have a group label. Again, if they don't, they won't show up on a group-specific build board.

Other issues just define that, for instance, anything in or to the left of ~"workflow::ready for development" should be moved as a milestone comes to a close. A full list of grooming issues is available by filtering by the ~"Plan stage grooming" label.

Retrospectives

The Plan stage conducts monthly retrospectives in GitLab issues. These are confidential during the initial discussion, then made public in time for each month's GitLab retrospective. For more information, see team retrospectives.

The retrospective issue is created by a scheduled pipeline in the async-retrospectives project. For more information on how it works, see that project's README.

Meetings

Most of our group meetings are recorded and publicly available on YouTube in the Plan group playlist.

Weekly group meeting

The only regular meeting we have is a Wednesday group-wide meeting. Because of timezone constraints, not everyone is able to attend, and the meeting is currently more suitable for people in EMEA and the eastern side of the Americas.

The agenda follows this format:

  1. Team updates: new hires, transfers, promotions, people leaving, etc.
  2. Big-picture updates: these are typically either forward-facing (vision statements), or backwards-looking (how a feature impacted users, sales, etc.).
  3. Issue-specific discussion and demos: any issues that people want to share with the wider group, that can't be handled using our normal asynchronous workflow.
  4. Workflow: how we improve how we work together in future (including updating this page).
  5. Anything else.

If there are no agenda items eight hours prior to the call, we skip the call entirely.

Process Improvements We're Working Towards

Metrics

Our stage level dashboard (internal) is a work in progress and is where we keep track of SMAU, feature usage, and other metrics we care about.

Plan SMAU

We have two versions for SMAU, with the "loose" version currently taking precedence as our Stage's externally communicated "North Star". It is our hope and long term goal to move away from defining our success according to vanity metrics and move towards a more congruent model that is based upon actual feature usage and adoption.

Loose Definition

The definitive metric is driven by total count of unique users with one or more page views over a given reporting period, where views attributable to the Plan Stage are being derived from the following paths:

Strict Definitions

We are currently in the process of implementing the necessary telemetry instrumentation to properly track the "strict" definition. The definitive metric is driven by total count of unique users with one or more actions over a given reporting period, where actions attributable to the Plan Stage are being derived from the following events:

Project Management - Issue Tracking
Project Management - Issue Boards
Project Management - Time Tracking
Portfolio Management - Agile Portfolio Management
Certify - Service Desk