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.
We use the Engineering workflow when working on issues and merge requests across multiple projects.
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
We plan and groom issues in advance of finalizing a milestone commitment on
M-1, 13th and before beginning development on
We tag each issue with the correct milestone, viewable on the milestone board
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.
Prioritization is a collaboration between Product, UX, Data, and Engineering. We use the
ICE framework for experiments. Each
Deliverable issue will have an ICE score.
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.
|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. The main goal of our planning and estimation is to focus on the 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.
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
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
Our primary method of tracking milestone progress is through our workflow board. 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.
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.
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:
!12345 - 50% complete- Working on tests and refactoring
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.
The following people are permanent members of the Acquisition Group:
|Jerome Ng||Engineering Manager, Growth:Acquisition and Conversion|
|Alex Buijs||Senior Fullstack Engineer, Growth:Acquisition|
|Nicolas Dular||Senior Fullstack Engineer, Growth:Acquisition|
|Alper Akgun||Senior Fullstack Engineer, Growth:Conversion|