The Acquisition, Conversion, and Backend Telemetry Groups are part of the Growth section. 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, the Conversion group, the Telemetry group or by creating an issue in our Workflow board.
The following people are permanent members of the Acquisition, Conversion, and Backend Telemetry Group:
|Jerome Ng||Backend Engineering Manager, Growth:Acquisition and Conversion and Telemetry|
|Alina Mihaila||Backend Engineer, Telemetry|
|Alex Buijs||Senior Fullstack Engineer, Growth:Acquisition|
|Nicolas Dular||Senior Fullstack Engineer, Growth:Acquisition|
|Alper Akgun||Senior Fullstack Engineer, Growth:Conversion|
|Dallas Reedy||Fullstack Engineer, Growth:Conversion|
Our team follows the Product Development Flow utilizing all labels from
~workflow::verification. We adhere to the Completion Criteria and Who Transitions Out outlined in the Product Development Flow to progress issues from one stage to the next.
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:
|Acquisition Workflow||Acquisition Workflow||Acquisition Workflow||-|
|Conversion Workflow||-||Conversion Workflow||-|
|Telemetry Workflow||-||Telemetry Workflow||-|
Our work is planned and delivered on a monthly cycle using milestones. Our team follows the Product Development Timeline utilizing all dates including from
M-1, 4th: Draft of the issues to
M+1, 4th: Public Retrospective.
We use milestone boards for high level planning and roadmapping across several milestones.
|Acquisition Milestones||Acquisition Milestones||Acquisition Milestones|
|Conversion Milestones||-||Conversion Milestones|
|Telemetry Milestones||-||Telemetry Milestones|
Planning a milestone requires sufficient lead time and close collaboration between Product, Engineering, and UX. In addition to the Product Development Timeline, we need to ensure the following tasks are completed:
~workflow::planning breakdownby month
M-1, 4th(at least 14 days before milestone m begins).
~workflow::ready for developmentby month
M-1, 13th(at least 5 days before milestone m begins).
We utilize a milestone planning issue to keep our team organized during the planning phase. Here is an example milestone planning issue. A milestone planning issue consists of:
The following tasks need to be completed for planning a milestone:
~workflow::planning breakdownthen move to
~workflow::schedulingwith the current milestone until milestone capacity is reached and milestone commitment is made.
~workflow::ready for development.
~workflow::ready for development
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:
In this example, the current milestone capacity is 31 weights.
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
We focus on scoping product changes into the minimal viable change.
To help our team be efficient, we explicitly define how our team uses issues.
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.
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.
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.
We have two types of issues we work with:
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 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:
Child issues are small broken down issues of Parent Issues. These issues are typically focused on engineering implementation or design work.
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.
~"workflow::ready for development,
~"workflow::In dev, etc.
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.
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:
The work done by our engineering teams mainly fall into two categories: PM Initiatives and Engineering Initiatives.
PM Initiatives: This work is primarily related to driving value for our customers. This work is typically outlined by the product manager in the milestone planning issue.
Engineering Initiatives: This work is primarily related to driving value for internal teams. Some examples of this work are bug fixes, follow-up issues, refactoring, career development work, or anything an engineer thinks is important enough to be worked on.
Engineers should aim to prioritize PM Initiatives to accomplish each milestone, however, they can also work on Engineering Initiatives during any down time or by carving out dedicated time during capacity planning. We should aim to carve out dedicated time for Engineering Initaitives that take one or more full working days. To carve out time, simply add a comment to the milestone planning issue. Here's an example of carving out time for Performance training.
We have daily asynchronous standups using status hero's 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:
Each group holds synchronus meetings at least once a week to gain additional clarity and alignment on our async discussions.
The agenda for each meeting is structured around the Product Development Flow.
workflow::ready for development,
One of our main engineering metrics is 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. Read more about why we adoped this model.
We aim for 10 MRs per engineer per month which is tracked using our throughput metrics dashboard.