@@ -398,7 +398,7 @@ keeping with the overall goals of the group and adherence to broader
The Environments group uses epics to describe features or capabilities that will increase the maturity of the Environments categories over time.
Each epic should be owned by an engineer who is responsible for all technical aspects of that epic. The engineering DRI will work closely with the Product Manager and Product Designer to understand the requirements and create issues that encapsulate the technical work required during the [design](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-3-design)/[solution validation](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-4-solution-validation) phases and [build](/handbook/product-development/how-we-work/product-development-flow/#build-track) track of the [Product Development Flow](/handbook/product-development/how-we-work/product-development-flow/). Each issue needs to be weighted and contain enough information in the description area for any other engineer on the team to be able to pick up that work.
Each epic should be owned by an engineer who is responsible for all technical aspects of that epic. The engineering DRI will work closely with the Product Manager and Product Designer to understand the requirements and create issues that encapsulate the technical work required during the [design](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-4-design)/[solution validation](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-5-solution-validation) phases and [build](/handbook/product-development/how-we-work/product-development-flow/#build-track) track of the [Product Development Flow](/handbook/product-development/how-we-work/product-development-flow/). Each issue needs to be weighted and contain enough information in the description area for any other engineer on the team to be able to pick up that work.
**For the duration of building the epic**, the engineer does not need to be the only person implementing the issues. They should keep watch of the work that is done on the issues so that they can verify that the work is progressing correctly. If there are problems with the work, or lengthy delays,
they need to make sure the Product Manager and Engineering Manager are aware.
@@ -684,7 +684,7 @@ Suppose working one milestone ahead to design the big solution is not possible.
#### Avoiding crunch times between UX, Product and Engineering
- Ideally, Product Management and Product Designers aim to work 3 months in advance of Engineering proposals to ensure the problem definition and solution has been adequately validated prior to building. See [Validation track](/handbook/product-development/how-we-work/product-development-flow/#validation-track) for more details. This allows us to come up with the bigger idea ahead of time, and work further with Engineering to break it down into smaller iterations. Ideally, this should be completed before the implementation milestone starts.
- the Product Designer, PM, and Engineering use the [Design phase](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-3-design) in the Validation track to talk about complexities and discuss challenges and uncover blockers. Once we are all in agreement, we can move it to the [Solution Validation phase](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-4-solution-validation).
- the Product Designer, PM, and Engineering use the [Design phase](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-4-design) in the Validation track to talk about complexities and discuss challenges and uncover blockers. Once we are all in agreement, we can move it to the [Solution Validation phase](/handbook/product-development/how-we-work/product-development-flow/#validation-phase-5-solution-validation).
- If it is taking more than a week to understand and investigate the technical feasibility for the design solution, update the workflow label to `~workflow::blocked` and change the assignee to engineering DRIs until the technical discussion is resolved. If the discussion is expected to go on longer, reducing the chances of the design solution being delivered in the intended milestone, consider creating [a spike issue](/handbook/engineering/devops/verify/pipeline-execution/#spikes) for the discussion that blocks the current issue.
- Engineers and Product Designers should stay in contact and frequently align throughout the [Build track](/handbook/product-development/how-we-work/product-development-flow/#build-track) to avoid unplanned changes.
@@ -70,8 +70,8 @@ work toward overall team priorities and goals laid out by the team managers.
Distribution groups use the [GitLab product development flow](/handbook/product-development/how-we-work/product-development-flow/#workflow-summary) and labels in principle, we usually skip below phases due to the nature of our work:
@@ -70,8 +70,8 @@ work toward overall team priorities and goals laid out by the team managers.
Distribution groups use the [GitLab product development flow](/handbook/product-development/how-we-work/product-development-flow/#workflow-summary) and labels in principle, we usually skip below phases due to the nature of our work:
@@ -23,8 +23,8 @@ Following [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)) approach
We also use the [GitLab product development flow](/handbook/product-development/how-we-work/product-development-flow/#workflow-summary) and labels in principle. However, we usually skip below phases due to the nature of our work:
