Plan:Product Planning & Plan:Certify Backend Team

1. You are here:
2. Engineering
3. Development Department
4. Dev Sub-department
5. Plan:Product Planning & Plan:Certify Backend Team

Maintained by:

On this page

• Plan:Product Planning & Plan:Certify backend team
  • Team members
  • Stable counterparts
  • Hiring chart
  • Team metrics dashboard
  • Application performance dashboard
• OKRs
• Scalability Targets
  • Stage-wide
  • Product Planning & Certify
• Work
  • Capacity Planning
    • Weighing bugs
    • Planning Rotation
    • Consider a Spike and/or a Design Document
    • Historical Capacity
  • Collaborating with Frontend
    • Workflow Labels
    • Using the ~"backend complete" label
    • Documentation
  • Picking something to work on
    • High Severity Issues
  • Working on unscheduled issues
• Useful links

Plan:Product Planning & Plan:Certify backend team

The Plan:Product Planning & Plan:Certify backend team works on the backend part of GitLab's Product Planning and Certify categories in the Plan stage.

For more details about the vision for this area of the product, see the Plan stage page.

Team members

Stable counterparts

Hiring chart

Check out our jobs page for current openings.

Team metrics dashboard

We have a metrics dashboard intended to track against some of the Development Department KPIs, particularly those around merge request creation and acceptance. From that dashboard, the following charts show MR Rate and Mean time to merge (MTTM) respectively.

The following chart shows the MR Rate of the Dev section as a whole, for the identification of trends:

Application performance dashboard

We have useful dashboards tracking the performance of parts of the application we're responsible for:

• Application dashboards; showing request throughput, latency, SQL query counts, cache hits, Sidekiq jobs for Web and API endpoints, git usage and error budgets. Also links to other useful resources in Kibana.
  • Product Planning
  • Certify
• The Sitespeed Dashboard; showing the results of ongoing synthetic tests against representative product pages. Useful for identifying changes in page load time (TTFB), LCP, etc.

OKRs

Active Quarter OKRs

Previous: FY22-Q2

• Improved visibility and understanding of scalability (Epic)

Scalability Targets

Stage-wide

We're tracking a number of issues that we believe could cause scalability problems in the future.

Note: Work is ongoing on migration helpers to mitigate Int4 Primary Key Overflows. These will provide a standard way to resolve these issues.

Product Planning & Certify

Work

See the Plan stage page and the Plan:Project Management backend team page.

Capacity Planning

We use a lightweight system of issue weighting to help with capacity planning, with the knowledge that things take longer than you think. These weights are used for capacity planning and the main focus is on making sure the overall sum of the weights is reasonable.

It's OK if an issue takes longer than the weight indicates. The weights are intended to be used in aggregate, and what takes one person a day might take another person a week, depending on their level of background knowledge about the issue. That's explicitly OK and expected.

These weights we use are:

Anything larger than 5 should be broken down if possible.

We look at recent releases and upcoming availability to determine the weight available for a release.

Weighing bugs

Estimating bugs is inherently difficult. The majority of the effort in fixing bugs is finding the cause, and then a bug 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, or we need to switch state management to Vuex on the frontend), 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.

Planning Rotation

To assign weights to issues in a future milestone, we ask two team members to take the lead each month. They can still ask questions - of each other, of the rest of the team, of the stable counterparts, or anyone else - but they are the initial. This should start on the 4th of the month, per the Product Development Timeline.

To weight issues, they should:

1. Look through all issues with the ~"workflow::planning breakdown" label, filtered by your group, ~backend and ~"Next Up" (you can use the links in the table below).
2. For those they understand, they add a weight. If possible, they also add a short comment explaining why they added that weight, what parts of the code they think this would involve, and any risks or edge cases we'll need to consider.
3. For issues that already have a weight check that it's still appropriate for the work required, which may have changed since the effort was last estimated.
4. Timebox the issue weighting overall, and for each issue. The process is intended to be lightweight. If something isn't clear what weight it is, they should ask for clarification on the scope of the issue.
5. If two people disagree on the weight of an issue, even after explaining their perceptions of the scope, we use the higher weight.

The rotation for upcoming releases is:

Consider a Spike and/or a Design Document

Work that arrives in ~"workflow::ready for development" that is out of scope or ill-defined should be returned to ~"workflow::planning breakdown" for further refinement. To avoid the disruption this introduces we try to reduce the number of times it happens by planning more carefully. While it's not always possible, we aim to identify complexity before the build phase. For this reason, we assign a backend DRI to help with each upcoming deliverable during design and validation phases.

However, sometimes complexity can't be accurately estimated until development work starts. If you anticipate this during planning, consider creating a spike to produce a design document. Notify the participants in the issue, especially the PM, that a spike is required, create a separate issue and follow these steps:

1. Title the issue with the goal of the spike;
2. Add the ~spike, ~backend, and corresponding stage/group labels;
3. List the unknowns and questions to be answered;
4. List decisions, architectural or otherwise, that need to be made;
5. Identify counterparts you'll need help from (e.g. Frontend or UX) and establish a DRI;
6. Mark the issue as blocking the original, and
7. Label with ~"workflow::ready for development" and assign to the current milestone for someone to pick up.

The deliverable is a design document that answers the questions set out in the issue description. This can simply be the issue itself, containing a summary of the discussion in the description, answers to the questions and links to any PoC MRs produced.

Historical Capacity

Points of weight delivered by the team on the last three milestones, including rolling average. This allows for more accurate estimation of what we can deliver in future milestones. Full chart here.

Collaborating with Frontend

Workflow Labels

Most issues, especially features, involve working with other disciplines. A single issue will often be shared between frontend and backend and it can be difficult to know which workflow label should be applied, especially when progress is at different stages.

To ensure visibility for other team-members, for issues with a frontend and backend component:

• Assign yourself as early as possible if you have capacity to work on it;
• Move the issue to the top of ~"workflow::ready for development" until a frontend engineer is assigned;
• When both are assigned, consider hosting a small kickoff discussion.
• When the backend work is merged and verified add the ~"backend complete" label.

We value velocity over predictability so use your own judgement on whether you should wait for a frontend engineer to get involved before proceeding with development.

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.

Documentation

Documentation should accompany code for any new or changed functionality as per our definition of done. This can become tricky when collaborating on a feature that is behind a feature flag.

Since all feature flags start as disabled by default, we should aim to document the feature as soon as it's safe for testing by users using the feature flag template. Don't wait until a feature is performant and stable to document it, instead do so once it's secure and won't leave data in a corrupt, interim state.

Try to include docs with the first MR to introduce usable functionality. If this is an API addition with no UI, document that and allow the FE engineers to update it as work proceeds. As the feature flag rollout proceeds, the documentation should be updated.

This avoids the rush to provide documentation that often accompanies the release cutoff.

Picking something to work on

The team Build Board always shows work in the current release, with workflow columns relevant to implementation. Filtering it by ~backend shows issues for backend engineers to work on.

It's OK to not take the top item if you are not confident you can solve it, but please post in #s_plan if that's the case, as this probably means the issue should be better specified.

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

Everyone at GitLab has the freedom to manage their work as they see fit, because we measure results, not hours. Part of this is the opportunity to work on items that aren't scheduled as part of the regular monthly release. This is mostly a reiteration of items elsewhere in the handbook, and it is here to make those explicit:

1. We expect people to be managers of one, and we use GitLab ourselves. If you see something that you think is important, you can request for it to be scheduled, or you can work on a proposal yourself, as long as you keep your other tasks in mind.
2. From time to time, there are events that GitLab team-members can participate in, like the issue bash. Anyone is welcome to participate in these.
3. If you feel like you want to have some specific time set aside, but aren't interested in the topics of an existing event, feel free to label issues with "For Scheduling" and copy your manager for visibility.

When you pick something to work on, please:

1. Follow the standard workflow and assign it to yourself.
2. Share it in #s_plan - if not even more widely (like in #development or #backend).

Useful links

• Plan:Product Planning - Apply a milestone filter to see work in the current release
• #s_plan in Slack
• Recorded meetings
• Retrospectives
• Group Conversations (archive; group conversations now happen at a the section level)