Plan:Work Items Team

Plan:Work Items Team

The Plan:Work Items team works on GitLab’s Work Items group in the Plan stage. The group renamed from Project Management in the FY27 reorg.

What we own

The group owns three categories, plus the work items framework they run on (widgets and the GraphQL and REST APIs for work items).

• Team Planning: issues, tasks, labels, milestones, assignees, weights, dates, statuses, time tracking, discussions, internal notes, description templates, quick actions, work item types and settings, and merge request linking. See the Plan and track docs.
• Service Desk: service desk issues, custom email and branding, and customer relations management (CRM). See the Service Desk docs.
• Notifications: web and email notifications and to-dos. See the notifications docs.

Team members

Name	Role
Alexandru Croitor	Engineering Manager, Plan:Spec-Driven Development and Plan:Work Items
Agnes Slota	Backend Engineer, Plan:Work Items
Senior Frontend Engineer	Senior Frontend Engineer, Plan:Work Items
Deepika Guliani	Senior Frontend Engineer, Plan:Work Items
Mario Celi	Senior Backend Engineer, Plan:Work Items
Marc Saleiko	Staff Fullstack Engineer, Plan:Work Items

Stable counterparts

Name	Role
Costel Maxim	Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code, Growth, Fulfillment:Purchase, Fulfillment:Provision, Fulfillment:Utilization, Systems:Gitaly
Gabe Weaver	Senior Product Manager, Plan:Spec-Driven Development, Plan:Work Items, Plan:Planning Views, and Plan:Portfolio Planning
Heinrich Lee Yu	Principal Engineer, Plan
Natalia Tepluhina	Principal Engineer, Plan

Technical Writer is Brendan Lynch. For UX questions, @ mention Nick Brandt or Sunjung Park, the Product Design contacts for the Plan stage.

How we work

The Plan stage page describes how we work as a stage.

For the backend team specifically, we use the standard GitLab engineering workflow. To get in touch with the Plan:Work Items team, create an issue in the relevant project (typically GitLab) and add the ~“group::work items” label, along with any other appropriate labels. Then ping the relevant Product Manager or Engineering Manager as listed above.

For quick questions, use #g_work_items on Slack. #s_plan is the stage-wide channel and #s_plan_standup is the async standup.

Error budget

The error budget dashboard shows how the group is doing against its availability target.

The Engineering Excellence dashboard (internal, requires sign-in) shows velocity, reliability, correctness, security and efficiency for the Plan stage.

Capacity planning

Estimating effort

When estimating the effort involved in upcoming work, we use the same approach and numerical scale as other groups in the Plan stage.

When weighting an issue for a milestone, we use a lightweight, relative estimation approach, recognizing that tasks often take longer than you think. These weights are primarily used for capacity planning, ensuring that the total estimated effort aligns with each group’s capacity for a milestone.

Key Principles

• Relative Estimation: We focus on the relative complexity and effort required for each issue rather than precise time estimates.
• Aggregate Focus: The sum of all issue weights should be reasonable for the milestone, even if individual issues vary in actual time taken.
• Flexibility: It’s acceptable for an issue to take more or less time than its weight suggests. Variations are expected due to differences in individual expertise and familiarity with the work.

Weight Definitions

Weight	Meaning
1	Trivial, does not need any testing
2	Small, needs some testing but nothing involved
3	Medium, will take some time and collaboration
4	Substantial, will take significant time and collaboration to finish
5	Large, will take a major portion of the milestone to finish

Initial Planning: During milestone planning, tasks can be estimated up to a weight of 5 if necessary. However, as the milestone approaches and the team moves closer to starting implementation, any task with a weight larger than 3 should be decomposed into smaller, more manageable issues or tasks with lower weights.

Why This Approach: Allowing larger weights early on provides flexibility in high-level planning. Breaking down tasks closer to implementation ensures better clarity, reduces risk, and facilitates more accurate tracking and execution.

We assess the available capacity for a milestone by reviewing recent milestones and upcoming team availability. This ensures that our milestone planning remains realistic and achievable based on the collective effort estimated through these weights.

Weighing bugs

Estimating bugs is inherently difficult. The majority of the effort in fixing bugs is finding the cause, and then a bug can be accurately estimated. Additionally, velocity is used to measure the amount of new product output, and bug fixes are typically fixes on a feature that has been tracked and had a weight attached to it previously.

Because of this, we do not weigh bugs during ~“workflow::planning breakdown”. If an engineer picks up a bug and determines that there will be a significant level of effort in fixing it (for example, a large migration is needed), we then will want to prioritize it against feature deliverables. Ping the product manager with this information so they can determine when the work should be scheduled.

Refining and organizing feature work

To help drive alignment with our stable counterparts, provide visibility into progress, and breakdown our vision into a series of MVCs, we collaborate with Product and UX during ~workflow::planning breakdown to refine and organize ~type::feature deliverables into the following structure:

• Feature (Epic) - Contains all the necessary vertical feature slices to default the corresponding feature flag to “on”. The feature epic will also serve as the location to generate a corresponding Release Post item MR. The feature epic should be scoped to the minimal amount of functionality that still provides customer value. Additional scope planned for future enhancements should be stored in follow-on epics.
  • Spike (Issue) - If we are unable to accurately estimate the effort necessary to implement the feature, we first conduct a spike
  • UX (Issue) - For larger initiatives, UX creates a separate UX issue that serves as the SSOT for design goals, design drafts, design conversation and critique, and the chosen design direction that will be implemented. Learn more about UX issues.
  • Vertical Feature Slice (Issue) - A subset of the feature that can be completed within a single milestone, tested, and verified within the plan-stage group on production.
    • Engineering Tasks (Task - Optional) - One or more engineering tasks that need to be completed in order to deliver the vertical feature slice. The scope of a task should generally correlate to a single MR.

During the ~workflow::planning breakdown phase, all issues need to be weighted so we can efficiently and effectively collaborate with Product and UX on “right sizing” the feature epic. It’s advisable that all issues are connected to a parent epic that describes the broader set of improvements we are proposing within a specific area of the product. The desired outcome is to ensure it’s as small as possible, maximizes our ability to iterate, and makes it easy to track overall progress on delivery, while providing meaningful value and avoiding an undue amount of “change fatigue” for our customers.

Collaboration between backend and frontend

Using the ~“backend complete” label

The ~“backend complete” label is added to issues with multiple specializations (usually backend and frontend) to indicate that the backend component is complete. Add this label when the backend work is functionally complete, merged and verified but frontend, or other, work is ongoing.

Picking something to work on

Use the issues labeled group::work items in the current milestone for this milestone’s work, or the full list for everything. Filter by ~backend to see issues for backend engineers.

It’s OK to not take the top item if you are not confident you can solve it. Post in #g_work_items if that’s the case, as it probably means the issue needs a better spec.

High severity issues

When an issue comes through that is both ~“severity::1” and ~“priority::1”, our SLO requires that it be looked at right away. Other items being worked on should be postponed in favor of any investigations or work for the high severity/priority issue. When postponing an issue, engineers should leave a comment on the issue with a link to the high severity item that is being prioritized instead. Leaving a comment will help with communication with the cross-functional team and for historical tracking. The exception to this is if another “severity::1”/“priority::1” issue is currently being worked on by an engineer. If this is the case, the engineer should make others on the team aware of the new issue on Slack but then keep working on the initial issue.

Working on unscheduled issues

We follow the ownership mindset operating principle: the people closest to the work make the decisions about it, and they own the result. We also measure ourselves by customer outcomes, not by activity on our side. If you see something important that is not scheduled, you can request for it to be scheduled or work on a proposal yourself. Assign it to yourself and share it in #g_work_items.

Useful links

• Issues labeled group::work items
• Same list, current milestone
• Error budget dashboard
• Engineering Excellence dashboard for the Plan stage (internal)
• #g_work_items and #s_plan in Slack
• Current jobs