---
layout: handbook-page-toc
title: Acquisition, Conversion, and Backend Telemetry Group
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

## Vision

The Acquisition, Conversion, and Backend Telemetry Groups are part of the [Growth section](/handbook/engineering/development/growth/). The Acquisition Group is responsible for promoting the value of GitLab and accelerating site visitors transition to happy valued users of our product. The Conversion Group is responsible for continually improving the user experience when interacting with locked features, limits and trials. The Telemetry Group is responsible for the collection and analysis of data to improve GitLab's product which includes being the primary caretaker of the versions app.

**I have a question. Who do I ask?**
Questions should start by @ mentioning the Product Manager for the [Acquisition group](/handbook/product/categories/#acquisition-group), the [Conversion group](/handbook/product/categories/#conversion-group), the [Telemetry group](/handbook/product/categories/#telemetry-group) or by creating an issue in our [Workflow board](https://about.gitlab.com/handbook/engineering/development/growth/acquisition-conversion-be-telemetry/#workflow-boards).

## Team Members

The following people are permanent members of the Acquisition, Conversion, and Backend Telemetry Group:

<%= direct_team(manager_role: 'Engineering Manager, Growth:Acquisition and Conversion and Telemetry') %>

## How We Work

* In accordance with our [GitLab values](/handbook/values/)
* Transparently: nearly everything is public
* We get a chance to work on the things we want to work on
* Everyone can contribute; no silos
* We're data savvy

### Product Development Flow

Our team follows the [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/#workflow-summary) utilizing all labels from `~workflow::start` to `~workflow::verification`. We adhere to the **Completion Criteria** and **Who Transitions Out** outlined in the [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/#workflow-summary) to progress issues from one stage to the next.

#### Workflow Boards

We use workflow boards to track issue progress throughout a milestone cycle. Workflow boards should be viewed at the highest group level for visibility into all nested projects in a group.

There are three groups we use:
- The [gitlab.com/gitlab-org](https://gitlab.com/gitlab-org/) group includes the [gitlab](https://gitlab.com/gitlab-org/gitlab), [customers-gitlab-com](https://gitlab.com/gitlab-org/customers-gitlab-com), and [license-gitlab-com](https://gitlab.com/gitlab-org/license-gitlab-com) projects.
- The [gitlab.com/gitlab-com](https://gitlab.com/gitlab-com/) group includes the [www-gitlab-com](https://gitlab.com/gitlab-com/www-gitlab-com) project.
- The [gitlab.com/gitlab-services](https://gitlab.com/gitlab-services/) group includes the [version-gitlab-com](https://gitlab.com/gitlab-services/version-gitlab-com) project.

| gitlab-org | gitlab-com | gitlab-services | all groups |
| ------ | ------ | ------ | ------ |
| [Acquisition Workflow](https://gitlab.com/groups/gitlab-org/-/boards/1158847?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition) | [Acquisition Workflow](https://gitlab.com/groups/gitlab-com/-/boards/1546862?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition) | [Acquisition Workflow](https://gitlab.com/groups/gitlab-services/-/boards/1546865?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition) | [-](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition) |
| [Conversion Workflow](https://gitlab.com/groups/gitlab-org/-/boards/1158847?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aconversion) | [-](https://gitlab.com/groups/gitlab-com/-/boards/1546862?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aconversion) | [Conversion Workflow](https://gitlab.com/groups/gitlab-services/-/boards/1546865?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aconversion) | [-](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aconversion) |
| [Telemetry Workflow](https://gitlab.com/groups/gitlab-org/-/boards/1158847?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Atelemetry) | [-](https://gitlab.com/groups/gitlab-com/-/boards/1546862?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Atelemetry) | [Telemetry Workflow](https://gitlab.com/groups/gitlab-services/-/boards/1546865?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Atelemetry) | [-](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Atelemetry) |

### Product Development Timeline

Our work is planned and delivered on a monthly cycle using [milestones](https://docs.gitlab.com/ee/user/project/milestones/). Our team follows the [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline) utilizing all dates including from `M-1, 4th: Draft of the issues` to `M+1, 4th: Public Retrospective`.

#### Milestone Boards

We use milestone boards for high level planning and roadmapping across several milestones.

| gitlab-org | gitlab-com | gitlab-services |
| ------ | ------ | ------ |
| [Acquisition Milestones](https://gitlab.com/groups/gitlab-org/-/boards/1370834?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition) | [Acquisition Milestones](https://gitlab.com/groups/gitlab-com/-/boards/1547281?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition) | [Acquisition Milestones](https://gitlab.com/groups/gitlab-services/-/boards/1547332?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition) |
| [Conversion Milestones](https://gitlab.com/groups/gitlab-org/-/boards/1370834?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aconversion) | [-](https://gitlab.com/groups/gitlab-com/-/boards/1547281?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aconversion) | [Conversion Milestones](https://gitlab.com/groups/gitlab-services/-/boards/1547332?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aconversion) |
| [Telemetry Milestones](https://gitlab.com/groups/gitlab-org/-/boards/1370834?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Atelemetry) | [-](https://gitlab.com/groups/gitlab-com/-/boards/1547281?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Atelemetry) | [Telemetry Milestones](https://gitlab.com/groups/gitlab-services/-/boards/1547332?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Atelemetry) |

#### Planning a Milestone

Planning a milestone requires sufficient lead time and close collaboration between Product, Engineering, and UX. In addition to the [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline), we need to ensure the following tasks are completed:
- Milestone Planning issue is created and issues are created and put into `~workflow::planning breakdown` by month `M-1, 4th` (at least 14 days before milestone m begins).
- Milestone Commitment is finalized and all issues are tagged with the current milestone and moved into `~workflow::ready for development` by month `M-1, 13th` (at least 5 days before milestone m begins).

##### Milestone Planning Issue

We utilize a milestone planning issue to keep our team organized during the planning phase. Here is an [example milestone planning issue](https://gitlab.com/gitlab-org/gitlab/issues/198153#note_274957060). A milestone planning issue consists of:
- Holidays
- Capacity
- Deliverables
- User Experience
- Bug Fixes
- Security Fixes
- Technical Debt
- UX Debt
- OKR Alignment
- Things to Pay Attention To
- Planning Tasks

##### Planning Tasks

The following tasks need to be completed for planning a milestone:
* [ ] PM creates milestone planning issue
* [ ] Team updates holidays section
* [ ] Engineers update capacity section
* [ ] PM highlights work for Deliverables, User Experience, Bug Fixes, Security Fixes, Technical Debt, UX Debt sections
* [ ] PM describes how this milestone aligns with our team's OKRs
* [ ] Team highlights Things to Pay Attention To section
* [ ] PM moves all work into `~workflow::planning breakdown`
* [ ] PM assigns priority by using the scoped `~milestone::p1/p2/p3/p4` labels
* [ ] Engineers break down parent issues into child issues in `~workflow::planning breakdown`
* [ ] Engineers estimate issues in `~workflow::planning breakdown` then move to `~workflow::scheduling`
* [ ] Engineers create milestone commitment by tagging issues in `~workflow::scheduling` with the current milestone until milestone capacity is reached and milestone commitment is made.
* [ ] Engineers move issues into `~workflow::ready for development`.
* [ ] Engineers begin working on issues in `~workflow::ready for development`

##### Milestone Capacity

Our milestone capacity tells us how many issue weights we can expect to complete in a given milestone. This is calculated by taking the sum of issue weights completed in the last milestone prorated by holidays. If there is a large variation in the estimated capacity of the last milestone and the one before it, we will use an average estimated capacity of the last few milestones. Here is an example of how we calculate capacity:

**Last Milestone:**
* **Total weights completed:** 24
* **Available work days:** 21.6 * 1 engineers = 21.6 available days
* **Actual work days:** 21.6 available days - 5 days off = 16.6 actual days
* **Ratio of available:actual work days:** 21.6 / 16.6 = 1.30
* **Maximum capacity:** 24 * 1.3 = 31 weights

**Current Milestone:**
* **Available work days:** 21.6 days * 1 engineers = 21.6 available days
* **Actual work days:** 21.6 av-days - 0 days off = 21.6 actual days
* **Ratio of available:actual work days:** 21.6 / 21.6 = 1
* **Maximum capacity:** 31 * 1 = 31 weights

In this example, the current milestone capacity is 31 weights.

##### Milestone Commitment

A milestone commitment is a list of issues our team aims to complete in the milestone. After issues are broken down, estimated, and prioritized, we begin tagging issues with the current milestone until the sum of the tagged issue weights equals our team's milestone capacity.

The top 70% of a milestone's issues by weight will also be labelled as `~Deliverable` while the remaining 30% of issues will be labelled as `~Stretch`.

### How We Use Issues

To help our team be [efficient](/handbook/values/#efficiency), we explicitly define how our team uses issues.

#### Issue Creation

We aim to create issues in the same project as where the future merge request will live. For example, if an experiment is being run in the Customers application, both the issue and MR should be created in the Customers project.

We emphasize creating the issue in the right project to avoid having to close and move issues later in the development process. If the location of the future merge request cannot be determined, we will create the issue in our catch-all [growth team-tasks project](https://gitlab.com/gitlab-org/growth/team-tasks/issues).

#### Follow-up Issues

During development work it's common that follow-up issues get created. These issues should be labeled with `~workflow::scheduling` and the PM should prioritize some of these follow-up issues for each milestone to not accumulate too much technical debt over time.

**1:1 Ratio**

We aim to maintain a 1:1 ratio between issues and merge requests. For example, if one issue requires two merge requests, we will split the issue into two issues. We aim for a 1:1 ratio as we believe it emphasizes keeping MRs small, it makes estimation on issues straight forward, and it provides more visibility into an issue's progress.

#### Issue Hierarchy
We have two types of issues we work with:

##### Parent Issues
Parent issues are GitLab issues that are used to group several child issues together. These issues are typically focused on product and the high level overviews of a feature or experiment.

Our groups have decided to use Parent Issues instead of [epics](https://docs.gitlab.com/ee/user/group/epics/) due to some of the limitations with epics (not being able to add labels, add milestones, assign team members, or link issues across projects). Here are guidelines we follow when using parent issues:
- Acts as a single source of truth for a feature or experiment
- Consolidates all high level conversations
- Issue is labelled with `~link::parent issue`
- Child Issues are linked under "Linked issues"
- To see the progress of a parent issue, you can see the ratio of “Linked issues” that are open versus closed.
- Parent issues can sit in workflow::in dev while the Child Issue is being worked on.

##### Child Issues
Child issues are small broken down issues of Parent Issues. These issues are typically focused on engineering implementation or design work.
- Issue is labelled with `~link::child issue`
- Issue description should reference the Parent Issue
- Contains conversations about the finer details. High level conversations should be moved to the Parent Issue.
- It is fine to only provide limited details in a Child Issue, when the issue is just there to track the engineering work.

#### Issue Labels
We use issue labels to keep us organized. Every issue has a set of required labels that the issue must be tagged with. Every issue also has a set of optional labels that are used as needed.

**Required Labels**
- [Stage:](https://about.gitlab.com/handbook/engineering/development/growth/#how-we-work) `~devops::growth`
- [Group:](https://about.gitlab.com/handbook/engineering/development/growth/#how-we-work) `~group::acquisition`, `~group::conversion`, `~group::telemetry`
- [Workflow:](https://about.gitlab.com/handbook/product-development-flow/#workflow-summary) `~"workflow::planning breakdown`, `~"workflow::ready for development`, `~"workflow::In dev`, etc.
- [Parent Child Link:](https://about.gitlab.com/handbook/engineering/development/growth/acquisition-conversion-be-telemetry/#issue-hierarchy) `~link::parent issue`, `~link::child issue`

**Optional Labels**
- [Experiment:](https://about.gitlab.com/handbook/engineering/development/growth/#experiment-issue-creation) `~growth::experiment`
- [Experiment Status:](https://about.gitlab.com/handbook/engineering/development/growth/#experiment-issue-creation) `~"experiment::active`, `~"experiment::validated`, etc.
- [Release Scoping:](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/development/contributing/issue_workflow.md) `~Deliverable`, `~Stretch`
- [UX:](https://about.gitlab.com/handbook/engineering/development/growth/#ux-workflows) `UX`
- Other labels in [issue workflow](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/development/contributing/issue_workflow.md)

#### Merge Request Labels
MR labels can mirror issue labels (which is automatically done when created from an issue), but only certain labels are required for correctly [measuring throughput](#measuring-throughput).

**Required Labels**
- [Stage:](https://about.gitlab.com/handbook/engineering/development/growth/#how-we-work) `~devops::growth`
- [Group:](https://about.gitlab.com/handbook/engineering/development/growth/#how-we-work) `~group::acquisition`, `~group::conversion`, `~group::telemetry`
- [Throughput:](https://about.gitlab.com/handbook/engineering/management/throughput/#implementation) `~security`, `~bug`, `~feature`, `~backstage`

### Prioritization
Prioritization is a collaboration between Product, UX, Data, and Engineering. To help our group prioritize issues within a milestone, we utilize the milestone priority labels:
- `~"milestone::p1"`
- `~"milestone::p2"`
- `~"milestone::p3"`
- `~"milestone::p4"`

### Estimation
We use a light-weight estimation process using a fibonacci scale with a maximum weight of 5, where 5 indicates the work should be broken down into smaller, clearly defined issues.

| Weight | Description (Engineering) |
| ------ | ------ |
| 1 | Trivial: The simplest possible change. We are confident there will be no side effects. |
| 2 | Small: A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | Medium: A simple change, but the code footprint is bigger (e.g. lots of different files, or tests effected). The requirements are clear. |
| 5 | Large: A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way. |

In planning and estimation, we value [velocity over predictability](https://about.gitlab.com/handbook/engineering/#velocity-over-predictability). The main goal of our planning and estimation is to focus on the [MVC](https://about.gitlab.com/handbook/values/#minimum-viable-change-mvc), uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. We aim for 70% predictability instead of 90%. We believe that optimizing for velocity (MR throughput) enables our Growth teams to achieve a [weekly experimentation cadence](https://about.gitlab.com/handbook/product/growth/#weekly-growth-meeting).

- If an issue has many unknowns where it's unclear if it's a 1 or a 5, we will be cautious and estimate high (5).
- If an issue has many unknowns, we can break it into two issues. The first issue is for research, also referred to as a [Spike](https://en.wikipedia.org/wiki/Spike_(software_development)), where we de-risk the unknowns and explore potential solutions. The second issue is for the implementation.
- If an initial estimate is incorrect and needs to be adjusted, we revise the estimate immediately and inform the Product Manager. The Product Manager and team will decide if a milestone commitment needs to be adjusted.

### Async Daily Standups

We have daily asynchronous standups using [status hero's](https://statushero.com/integrations/gitlab) Slack integration. The purpose of these standups are to allow team members to have visibility into what everyone else is doing, allow a platform for asking for and offering help, and provide a starting point for some social conversations.

Three questions are asked at each standup:
* How do you feel today?
* What are you working on today?
  * Our status updates consist of the various issues and merge requests that are currently being worked on. If the work is in progress, it is encouraged to share details on the current state.
* Any blockers?
  * We raise any blockers early and ask for help.

### Sync Meetings

Each group holds synchronus meetings at least once a week to gain additional clarity and alignment on our async discussions.

* The Acquisition Group meets on Mondays 03:30pm UTC and Wednesdays 03:30pm UTC
* The Conversion Group meets on Tuesdays 02:00pm UTC and Thursdays 04:00pm UTC
* The Telemetry Group meets on Mondays 03:00pm UTC

**Meeting Agenda**

The agenda for each meeting is structured around the [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/#workflow-summary).
* Validation and Design (validation backlog, problem validation, design, solution validation)
* Planning (planning breakdown, scheduling, blocked, ready for development)
* In Development (in dev, in review, verification)
* FYI

**Meeting Rules**
* Agenda items should be filled in 6 hours before meetings otherwise it's possible to cancel the meeting.
* It's fine to add agenda items during the meeting as things come up in sync meetings we might not have thought about beforehand.
* Meetings start :30 seconds after start time
* Whoever has the first agenda item starts the meeting.
* Whoever has the last agenda item ends the meeting.
* Meetings end early or on time.
* Any missed agenda items are bumped to the next meeting.

## Measuring Throughput

One of our main engineering metrics is [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/) which is the total number of MRs that are completed and in production in a given period of time. We use throughput to encourage small MRs and to practice our values of [iteration](https://about.gitlab.com/handbook/values/#iteration). Read more about [why we adoped this model](https://about.gitlab.com/handbook/engineering/management/throughput/#why-we-adopted-this-model).

We aim for 10 MRs per engineer per month which is tracked using our [throughput metrics dashboard](https://app.periscopedata.com/app/gitlab/559676/Growth:Acquisition-and-Conversion-Development-Metrics).

## Common Links

* [Growth Section](/handbook/engineering/development/growth/)
* `#s_growth` in [Slack](https://gitlab.slack.com/archives/s_growth)
* [Growth Performance Indicators](/handbook/engineering/development/growth/performance-indicators/)
* [Growth Meetings and Agendas](https://docs.google.com/document/d/1QB9uVQQFuKhqhPkPwvi48GaibKDwGAfKKqcF-s3Y6og)