Changes for content/handbook/engineering/development/growth/engineering_dri.md: 2 added lines, 11 removed lines.
Original line number
Diff line number
Diff line
@@ -40,7 +40,7 @@ Early identification of potential risks and proactive collaboration with the tea
*Retrospective and Continuous Improvement*
Upon conclusion of each epic, a brief retrospective session should be facilitated to gather feedback on successes and areas for improvement. This practice helps refine processes and improves the handling of future epics.
Upon completion, when an epic exceeds the due date, or when any collaborator requests it, a brief retrospective session should be facilitated to gather feedback on successes and areas for improvement. This practice helps refine processes and improves the handling of future epics.
*Collaboration with Product and Design*
@@ -54,14 +54,5 @@ The appointed individual is empowered to identify when additional resources or s
### Standardized Status Update Template
To ensure consistency and clarity in our communication, we've implemented a standardized comment template for status updates across the Growth team.
This template streamlines our reporting process, making it easier for <abbrtitle="Directly Responsible Individual">DRI</abbr>s to provide comprehensive and uniform updates. By using a consistent format, we enhance readability and facilitate quick information retrieval for all team members.
To ensure consistency and clarity in our communication, we've implemented a standardized comment template for status updates across the Growth team, facilitated by the triage-ops bot on a specific day each week.
For guidance on using comment templates, please refer to our [Comment Templates Usage Guide](https://docs.gitlab.com/ee/user/project/description_templates.html#use-the-templates).
Growth follows the GitLab [Product Development Flow](/handbook/product-development/how-we-work/_index.md), supported by a series of automations that we’ve fine-tuned to improve clarity during refinement, streamline prioritization, and speed up experiment delivery.
@@ -15,23 +15,31 @@ Note: The Growth team currently operates as a single, unified team following a k
## Refinement Steps
### Epic-Level Refinement
### Epic-Level Workflow and Refinement
1. An epic is created and moved to problem validation using `~"workflow::problem validation"` where it is validated that the problem is clearly defined, worth solving, has no obvious blockers (legal, security, architectural), and the team has sufficient context to begin exploring solutions.
2. Once the problem is validated, if the epic requires UX/UI changes, it is labeled with `~"workflow::ready for design"` to enter the design phase. Note that not all epics need design (backend, API, and infrastructure work typically skip this). The designs created during this phase are exploratory and expected to evolve based on technical feedback during refinement.
3. After the epic is moved to refinement, a dedicated `refinement thread` is created by the bot where the team discusses technical risks, dependencies, and implementation complexity, and design can still be adjusted if refinement reveals technical constraints.
4. Once the discussions are concluded, to break down the epic, engineers can self-volunteer in the refinement thread and move the epic to `~"workflow::planning breakdown"`. If no volunteers emerge after seven business days from the time of refinement, the bot will tag the EM in the epic to manually assign an engineer based on relevant experience and capacity.
5. Once an engineer is assigned for breakdown, they move the epic to `~"workflow::planning breakdown"` to indicate decomposition is underway, and begin breaking down the epic into individual issues using the templates - [Experiment implementation](https://gitlab.com/gitlab-org/gitlab/-/issues/new?description_template=Experiment%20Implementation) for experiments, and [Implementation](https://gitlab.com/gitlab-org/gitlab/-/issues/new?description_template=Implementation) for everything else. Issues should use "blocking/blocked by" relationships to document implementation dependencies and required sequencing. If an issue's scope and weight are well understood at creation time, it can be directly labeled `~"workflow::scheduling"` with appropriate weight estimates, bypassing the formal issue refinement process. However, if the issue requires further clarification or has unclear implementation details, it should be labeled `~"workflow::refinement"` to go through the standard issue refinement process individually. Once all issues from the epic breakdown are created and appropriately labeled, the engineer moves the epic itself to `~"workflow::scheduling"` to indicate the breakdown is complete and the epic is ready for PM/EM to schedule the constituent issues into milestones based on team capacity and strategic priorities. All issues are placed on the team's kanban board and engineers pick up work based on their capacity.
6. The epic status needs to be moved to `~"workflow:: in dev"` once the the issues are getting worked upon.
1. Epic is created and moved to `~"workflow::problem validation"` where we validate the problem is clear, worth solving, and has no blockers. Product Manager owns the Epic during this phase.
2. If the Epic needs UX/UI changes, it's labeled `~"workflow::ready for design"` for design work (non UX/UI focused Epics skip this step).
3. Epic moves to `~"workflow::refinement"` and triage-bot creates a refinement thread where the team discusses technical approach, risks, and dependencies. If refinement reveals significant complexity, technical constraints, or timeline concerns that conflict with other committed work, engineers should flag these immediately and negotiate scope adjustments, implementation approach, or timeline expectations with PM/Design before proceeding to breakdown. The Engineering and Product Management must acknowledge and address these concerns before the epic can move forward.
4. Once the scope is clear, Engineers volunteer and self-assign the Epic to further breakdown the Epics into issues. If no volunteers after 3 business days from the time `~"workflow::refinement"` state, triage-bot tags EM to assign someone. Epic ownership transfers from PM to the volunteering Engineer, who becomes the [Engineering DRI](/handbook/engineering/development/growth/engineering_dri/) for the Epic.
5. The assigned engineer (now Engineering DRI) breaks the Epic into issues using [Experiment Implementation](https://gitlab.com/gitlab-org/gitlab/-/issues/new?description_template=Experiment%20Implementation) or [Implementation](https://gitlab.com/gitlab-org/gitlab/-/issues/new?description_template=Implementation) templates. Issues are labelled with `~"workflow::blocked"` with "blocking/blocked by" relationships to signal sequential execution.
6. Issues with clear scope get labeled `~"workflow::ready for development"` with weight estimates (skips issue refinement), while unclear issues get labeled `~"workflow::refinement"` to go through [issue refinement process](#issue-level-refinement).
7. Once all issues are created, labeled and refined, the Engineering DRI moves Epic to `~"workflow::ready for development"` to indicate breakdown is complete.
8. Once the issues inside the Epic are being worked on, the Engineering DRI moves the Epic to `~"workflow::in dev"`. A due date should be attached to estimate the delivery timeframe.
9. The Engineering DRI continues to own the Epic throughout the implementation phase, coordinating work across issues, managing dependencies, providing weekly status updates, and ensuring steady progress until all issues are completed.
10. When implementation is completed, Epic is moved to `~"workflow::verification"` and the Engineering DRI determines the appropriate verification level-either mentioning the PM and closing for straightforward completions, or requesting formal PM verification for complex changes.
{{% alert title="⚠️ Note" color="warning" %}}
Being the engineering DRI for an epic doesn't mean you have to implement every issue in it. The DRI is a coordinator, not a sole implementer. Other engineers pick up issues from the kanban board and contribute to the epic - the DRI ensures the work fits together and the epic reaches completion.
{{% /alert %}}
### Issue-Level Refinement
1. Issues are moved from `~"workflow::planning breakdown"` to `~"workflow::refinement"` automatically by the triage bot in order of priority (from top to bottom). The bot will only move issues to refinement if there is room in refinement column, meaning there is less issues than maximum limit for this column. This is first chance for PMs to prioritize issues by moving them higher in the `planning breakdown` column. After the issue is moved to refinement, a dedicated `refinement thread` is created, which acts as a place for discussion and weight estimation.
- 💡 Hint: In rare case when an issue has to be expedited, it's possible to move it to refinement manually. This will invoke a reaction from triage bot, which will add `refinement thread` for such issue instantly so the refinement can proceed the same way as with automated path.
2. During refinement the team ensures that the issue is well described and requirements are clear. They can use the `refinement thread` to discuss but they should make sure that any changes and decisions made there are also reflected in issue's description. Once each engineer is comfortable with the way the issue is described, they can vote their estimation of weight based on our [guidelines](#estimation-guidelines). The voting happens by reacting to the thread with one of few possible weight estimates: 1️⃣ 2️⃣ 3️⃣ 5️⃣ or 🚀.
- 💡 Hint: In rare case when an issue has to be expedited, it's possible to move it to refinement manually by adding the `~"workflow::refinement"` label. This will invoke a reaction from triage bot, which will add `refinement thread` for such issue instantly so the refinement can proceed the same way as with automated path.
2. During refinement the team ensures that the issue is well described and requirements are clear. They can use the `refinement thread` to discuss but they should make sure that any changes and decisions made there are also reflected in issue's description. Once each engineer is comfortable with the way the issue is described, they can vote their estimation of weight based on our [guidelines](#estimation-guidelines). The voting happens by reacting to the thread with one of few possible weight estimates: 1️⃣ 2️⃣ 3️⃣ 5️⃣ or 🚀 (indicates 5+).
3. Each day the triage bot checks all issues in `~"workflow::refinement"` column and if an issue has required minimum number of estimation votes (see `MIN_REACTIONS` constant [here](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/lib/growth_refine_automation_helper.rb?ref_type=heads#L16) for the current setting) it will be moved to `~"workflow::scheduling"`.
- 💡 Hint: If there is some problem with the issue and it shouldn't be moved forward even if enough engineers estimate it, ❌ reaction can be added to the thread which will stop the bot from transitioning the issue to `~"workflow::scheduling"` as long as this reaction sticks to the thread. This means that whoever put it is also responsible for removing it once the problem is gone.
4. Once the issue is in `~"workflow::scheduling"`, it is awaiting final prioritization by PMs - it has to be manually moved to `~"workflow::ready for dev"` depending on the current priorities. This part of the process is PMs responsibility. This allows for additional fine-tuning of priorities and acts as a buffer for our ready for development column.
4. Once the issue is in `~"workflow::scheduling"`, it is awaiting final prioritization by PMs - it has to be manually moved to `~"workflow::ready for development"` depending on the current priorities. This part of the process is PMs responsibility. This allows for additional fine-tuning of priorities and acts as a buffer for our ready for development column.
## Estimation Guidelines
@@ -39,12 +47,11 @@ Note: The Growth team currently operates as a single, unified team following a k
| Weight | LoE (Business Days) | Description |
| ------ | ------ | ------ |
| 1 | 1-2 days | The simplest possible change. We are confident there will be no side effects. |
| 2 | 2-3 days | A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | 3-5 days | A simple change, but the code footprint is bigger (e.g. lots of different files, or tests affected). The requirements are clear. |
| 5 | 5-8 days | 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. |
| 8 | 8-13 days | A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements. |
| 13 | 13-18 days | A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break into smaller issues. |
| 1 | 1-3 days | The simplest possible change. We are confident there will be no side effects. |
| 2 | 4-6 days | A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | 7-9 days | A simple change, but the code footprint is bigger (e.g. lots of different files, or tests affected). The requirements are clear. |
| 5 | 10-12 days | 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. |
| 5+ | 2 weeks+ | A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break into smaller issues. |
- LoE => Level of Effort represents the total number of business days spent across both `workflow::in dev` and `workflow::review` phases.
@@ -56,7 +63,7 @@ In planning and estimation, we value [velocity over predictability](/handbook/en
## Team Participation in Refinement
Operating asynchronously means refinement can't rely on scheduled meetings where everyone shows up at the same time. Instead, the team should adopt a continuous refinement mindset where engineers regularly check the growth epic board and issue kanban board for items in refinement status. When an epic appears in ~"workflow::refinement", engineers should review the refinement thread, ask clarifying questions, evaluate technical feasibility, and provide feedback on the proposed direction. This isn't a passive activity - the goal is to surface concerns, suggest alternatives, and ensure the epic is well-understood before someone volunteers to break it down.
Operating asynchronously means refinement can't rely on scheduled meetings where everyone shows up at the same time. Instead, the team should adopt a continuous refinement mindset where engineers regularly check the [growth Epic board](https://gitlab.com/groups/gitlab-org/-/epic_boards/2079888) and issue kanban board for items in refinement status. When an Epic appears in ~"workflow::planning breakdown", engineers should review the refinement thread, ask clarifying questions, evaluate technical feasibility, and provide feedback on the proposed direction. This isn't a passive activity - the goal is to surface concerns, suggest alternatives, and ensure the Epic is well-understood before someone volunteers to break it down.
Similarly, the issue kanban board should be monitored for issues in ~"workflow::refinement", ~"workflow::scheduling", and ~"workflow::ready for development". Issues in refinement need estimation votes and technical feedback. Issues in scheduling are waiting for final prioritization but are already well-defined and could be moved to ready for development if priorities shift. Issues in ready for development are immediately available for pickup. By regularly scanning these columns, engineers maintain awareness of upcoming work, can identify issues that align with their expertise or interests, and keep the pipeline moving.
