Commit 109e1eda authored by Jerome Ng's avatar Jerome Ng

Deleted...

Deleted source/handbook/engineering/development/growth/acquisition/index.html.md.erb, source/handbook/engineering/development/growth/conversion/index.html.md.erb files
parent 3afdb155
Pipeline #102153042 passed with stages
in 11 minutes and 16 seconds
---
layout: handbook-page-toc
title: Acquisition Group
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
## Vision
The Acquisition Group is part of the [Growth section]
and is responsible for promoting the value of GitLab and accelerating site visitors transition to happy valued users of our product.
* 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)
or create an issue in the [Growth issues board].
## How we work
* We're data savvy
* In accordance with our [GitLab 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
## Workflow
We use the [Engineering workflow](/handbook/engineering/workflow/) when working on issues and
merge requests across multiple projects.
### Timeline
We plan in monthly cycles using [milestones](https://docs.gitlab.com/ee/user/project/milestones/) following the [Product development timeline](/handbook/engineering/workflow/#product-development-timeline). To ensure we adhere to this monthly cycle, we pay special attention to these dates:
* `M-1, 13th`: Milestone commitment finalized
* `M-1, 18th`: Begin milestone
* `M, 17th`: End milestone
* `M, 19th`: Begin group retro
* `M, 22nd`: Release day
* `M, 26th`: End group retro
### Planning and Prioritization
We plan and groom issues in advance of finalizing a milestone commitment on `M-1, 13th` and before beginning development on `M-1, 18th`.
We tag each issue with the correct milestone, viewable on the [milestone board](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)
At times a single deliverable will be broken in to mutliple issues. One of these issues should be labelled as the `Deliverable` while the other issues are dependencies and are linked to the `Deliverable` issue. Once all dependency issues have been delivered, the issue with the `Deliverable` label can be closed. Deliverables by milestone are viewable on the [milestone deliverables board](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&label_name[]=Deliverable).
Prioritization is a collaboration between Product, UX, Data, and Engineering. We use the
[ICE framework](/direction/growth/#growth-ideation-and-prioritization) for experiments. Each `Deliverable` issue will have an ICE score.
### Estimation
We use a light-weight estimation process using a fibonacci scale with a maximum weight of 5. Anything over a 5 (large) 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.
### Milestone Commitment
A milestone commitment is a list of issues our team aims to complete in the milestone.
Our milestone commitments are based off of our team's estimated capacity, which is the sum of issue weights completed in the last milestone. If there's too much variance between the last milestone and the one before it, we will use an average of the last few milestones.
In the planning phase, once issues are groomed, estimated, and prioritized, we begin loading issues into the milestone commitment until the sum of the loaded issue weights equals our team's estimated capacity. The loaded issues are our milestone commitment. Each issue should be labelled with the correct milestone along with a `Deliverable` or `Stretch` label. The top 70% of a milestone's issues should be labelled as `Deliverable` while the remaining 30% of issues should be labelled as `Stretch`. [Read more about how these labels are used]([https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/development/contributing/issue_workflow.md#release-scoping-labels])
### Tracking Milestone Progress
Our primary method of tracking milestone progress is through our [workflow board](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). We keep all issues up to date with the correct workflow labels. Any time the status of an issue changes, we add a detailed comment in each issue providing additional context.
### Measuring Engineering 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).
### Daily Standups (Async)
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, we provide the estimated percentage complete.
> `!12345 - 50% complete` - Working on tests and refactoring
* Any blockers?
* We raise any blockers early and ask for help.
### Meetings (Sync)
We hold synchronus meetings twice a week on Mondays 03:30pm UTC and Wednesdays 03:30pm UTC. These meetings are used to additional gain clarity and alignment on our async discussions.
* In Development
* Blockers
* Existing Experiments
* Planning
* Grooming
* Design Review
* Estimation
* Milestone Commitments
* Retro
* What went well
* What didn’t go well
* What can be improved
## Team Members
The following people are permanent members of the Acquisition Group:
<%= direct_team(manager_role: 'Engineering Manager, Growth:Acquisition and Conversion') %>
## Common Links
* [Growth section]
* [Growth issues board]
* `#s_growth` in [Slack](https://gitlab.slack.com/archives/s_growth)
* [Growth Performance Indicators]
* [Fulfillment issues board]
* `#g_fulfillment` in [Slack](https://gitlab.slack.com/archives/g_fulfillment)
* [Telemetry issues board]
* `#g_telemetry` in [Slack](https://gitlab.slack.com/archives/g_telemetry)
* [Growth opportunities]
* [Growth meetings and agendas]
* [GitLab values]
[GitLab values]: /handbook/values/
[Growth section]: /handbook/engineering/development/growth/
[Growth issues board]: https://gitlab.com/groups/gitlab-org/-/boards/1158847
[Growth opportunities]: https://gitlab.com/gitlab-org/growth/product
[Growth meetings and agendas]: https://docs.google.com/document/d/1QB9uVQQFuKhqhPkPwvi48GaibKDwGAfKKqcF-s3Y6og
[Growth Performance Indicators]: /handbook/engineering/development/growth/performance-indicators/
[Fulfillment issues board]: https://gitlab.com/gitlab-org/fulfillment/issues
[Telemetry issues board]: https://gitlab.com/gitlab-org/telemetry/issues
---
layout: handbook-page-toc
title: Conversion Group
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
## Vision
The Conversion Group is part of the [Growth section]
and is responsible for continually improving the user experience when interacting with locked features, limits and trials.
* I have a question. Who do I ask?
Questions should start by @ mentioning the Product Manager for the [Conversion group](/handbook/product/categories/#conversion-group)
or create an issue in the [Growth issues board].
### How we work
* We're data savvy
* In accordance with our [GitLab 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
## Team Members
The following people are permanent members of the Conversion Group:
<%= direct_team(manager_role: 'Engineering Manager, Growth:Acquisition and Conversion') %>
## Common Links
* [Growth section]
* [Growth issues board]
* `#s_growth` in [Slack](https://gitlab.slack.com/archives/s_growth)
* [Growth Performance Indicators]
* [Fulfillment issues board]
* `#g_fulfillment` in [Slack](https://gitlab.slack.com/archives/g_fulfillment)
* [Telemetry issues board]
* `#g_telemetry` in [Slack](https://gitlab.slack.com/archives/g_telemetry)
* [Growth opportunities]
* [Growth meetings and agendas]
* [GitLab values]
[GitLab values]: /handbook/values/
[Growth section]: /handbook/engineering/development/growth/
[Growth issues board]: https://gitlab.com/groups/gitlab-org/-/boards/1158847
[Growth opportunities]: https://gitlab.com/gitlab-org/growth/product
[Growth meetings and agendas]: https://docs.google.com/document/d/1QB9uVQQFuKhqhPkPwvi48GaibKDwGAfKKqcF-s3Y6og
[Growth Performance Indicators]: /handbook/engineering/development/growth/performance-indicators/
[Fulfillment issues board]: https://gitlab.com/gitlab-org/fulfillment/issues
[Telemetry issues board]: https://gitlab.com/gitlab-org/telemetry/issues
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment