Sync Growth refinement page with current triage-ops automation

## Work Progression Guidelines

**Problem Validation**

### Problem Validation {.h5}

- Product Manager validates that the problem is clearly defined, worth solving, and free of blockers

- Product Manager moves the status of the Epic/Issue to `Ready for Design`

**In-Design**

### In-Design {.h5}

- Product Designer creates an Issue under the Epic to create necessary Design

- Designer iterates on designs and gathers early feedback

- When the scope is clear and the discussions have been addressed, Designer/PM moves the Issue to `Planning Breakdown` status

- If there is no Design Issue, Product Managers creates a bare minimal implementation 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) and proceed to `Planning Breakdown` status

**Refinement**

### Refinement {.h5}

- 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 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.

- 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+).

- If an issue has a weight of `5` or higher, it likely needs to be broken down into smaller issues. If the associated Epic has a DRI assigned, the bot will notify the DRI to split the issue and move the new issues to refinement (otherwise, it will notify the EM). The bot will not allow the issue to progress until it has been properly broken down.

  - 💡 Hint: In rare case when an Issue has to be expedited, it's possible to move it to refinement manually by setting the Issue's status to `Refinement`. 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.

- 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+, meaning the Issue is likely too big and needs splitting into smaller Issues - please also suggest how by starting a discussion).

  - 💡 Hint: You can also try the [Growth Refinement Review](https://gitlab.com/gitlab-org/growth/ai/growth-refinement-review) AI skill to help with refinement.

  <!-- markdownlint-disable-next-line MD051 : the anchor is valid; lint miscomputes it because of the {.h5} heading attribute -->

- If an issue has a weight of `5` or higher, it likely needs to be broken down into smaller issues. The Engineering DRI of the associated Epic (or the EM, if no DRI is assigned) is responsible for splitting the issue and moving the new issues through refinement. To prevent the bot from progressing the original issue in the meantime, add a ❌ reaction to the refinement thread (see the hint in the [Development Phase](#development-phase) section below).

> ⚠️ Once design and refinement are complete, the planned design, functionality, and UX approach should be treated as stable. Changes proposed during development or review are expensive and disruptive. Use the design and refinement phases to get as confident as possible in the implementation plan before the development phase begins.

**Development Phase**

### Development Phase {.h5}

- 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"`.

- 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) for the current setting), the bot sets the Issue's weight to the highest voted value, reacts to the refinement thread with ✅, and moves the Issue 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.

- 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.

- Engineers pick the Issue from from `Ready for Development` and move the status to `In Dev`

- Engineers pick the Issue from `Ready for Development` and move the status to `In Dev`. The triage bot then assigns the current milestone to the Issue.

- Once the MR associated with the Issue reaches to review stage, the status of the Issue is changed to `In Review`

- Once the MR is merged and MR changes is deployed to production, the status of the Issue is changed to `Verification`

- If an Issue is moved to any post-refinement status (`Ready for development`, `In dev`, `In review`, `Verification`, `Blocked`, or `Complete`) while its weight is missing, the triage bot pings the person who moved it to assign a weight according to the [estimation guidelines](#estimation-guidelines).

**Verification**

### Verification {.h5}

- 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.

## Estimation Guidelines

[The development estimation is the time during `~"workflow::in dev"` until moved to `~"workflow::complete"`, key factor is the review cycle that is uncertain with pipeline failures and reviewer availability]

[The development estimation is the time spent in the `In dev` status until the Issue is moved to `Complete`, key factor is the review cycle that is uncertain with pipeline failures and reviewer availability]

| Weight | Usual Timeline | Description                                                                                                                                                                                                                                                                                      |

| ------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

## 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](https://gitlab.com/groups/gitlab-org/-/epic_boards/2079888) 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. Engineers who develop interest and context during refinement are encouraged to volunteer as the Engineering DRI by self-assigning the Epic. Once satisfied with the refinement, engineers add a ✅ reaction to the refinement thread to signal completion. This isn't a passive activity - the goal is to surface concerns, suggest alternatives, ensure the Epic is well-understood, and ideally volunteer to own the breakdown and implementation.

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::refinement", engineers should review it, ask clarifying questions, evaluate technical feasibility, and provide feedback on the proposed direction. Engineers who develop interest and context during refinement are encouraged to volunteer as the Engineering DRI by self-assigning the Epic. This isn't a passive activity - the goal is to surface concerns, suggest alternatives, ensure the Epic is well-understood, and ideally volunteer to own the breakdown and implementation.

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.