@@ -18,8 +18,8 @@ Note: The Growth team currently operates as a single, unified team following a k
### Epic-Level Workflow and Refinement
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.
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). Product designers create a UX issue under the epic to refine the designs and solicit early, informal feedback. When the designs are near-final, they are documented in the parent epic.
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. When all discussions are resolved, the product designer closes the UX issue and documents the final designs in the epic.
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).
