Additional engineering review of v1 pd-flow (13.5): phase structure/content
Based on much feedback over the months, as well as this recent survey on the product development flow, we are shifting the product development flow from a "step by step" to and "activities/outcomes" model. For further context, please look at parent epic &938 (closed) or the working group page: https://about.gitlab.com/company/team/structure/working-groups/product-development-flow/
We now need further engineering reviews, and appreciate your help!
For your review, please look directly at the draft preview page. We’ve moved fast so reviewing the multiple MRs will not be too helpful at this time. Best way to see the direction we’re headed is to pull up the preview page alongside the currently live product development flow page, and compare the phase content in both tracks side by side. That’s where most of the iteration has been done so far. Then you can provide feedback directly in this issue and ask questions as well in Slack #wg-product-development-flow
Please focus your feedback on these areas:
-
Build track phases:
-Have we removed steps or other content that will cause confusion?
-Do we have the right outcomes and activities listed?
-
Validation track phases:
-Is engineering involved where/how they should be in the Validation track phases?
-If not, where are they missing and how?
Feedback end of day Tuesday Oct. 13 would be great, as we are about to start dogfooding with 2 to 3 product teams.
This is an MVC, so much work is outstanding still. To get a sense of known outstanding issues, you can take a look at the pdflow board: https://gitlab.com/gitlab-com/www-gitlab-com/-/boards/2012861?label_name[]=wg-product-development-flow
KNOWN ISSUES:
-
The rest of the content on the page, including the workflow labels table, have not been swept for alignment with the latest content updates in the phases. So there will be discrepancies you can disregard, especially between the workflow table and the labels/DRIs in the phases.
-
We have not copy edited or done any sweep on style/language yet, so please refrain from detailed feedback in these areas.
Feedback received
-
Cut or move supplemental info. - already done. -
Clearly call out which phases are required. - already done. - Can tell what is required in the phases, but not which phases are necessary.
-
Change wording from "required" to "expected". - !70386 (closed) created and then closed because we are deliberately using the word required at this time and would like to await broader cross-functional feedback through 13.8/9 prior to changing the flow. This MR clarifies the intro to support how/why we're using "required" !70684 (merged) -
Describe the tracks. - already done. -
DRY up outcomes about issues/epics being kept current. - already done. -
Encourage experimentation/adaptation. - !70386 (closed) -
Make Planning Breakdown less prescriptive. - !70386 (closed) - "EM assigns engineers to..."
- Weights/estimation
-
Bring in workflow::refinement
as an option. - !70388 (merged) create and closed. We don't include optional steps/labels in the pd-flow anymore, to reduce bloat, we only include required ones. But teams can still leverage additional tactics/labels if desired. If teams think this needs to be required, a separate MR/discussion should be raised. This MR clarifies the intro to support how/why we're not including optional steps/labels !70684 (merged) -
Remove workflow::ready for review
. - already done !65301 (merged) -
Make job titles consistent. - !70389 (merged) -
Distinguish between issue/MR life cycles? -
Consolidate Outcomes and Activities
andRequired Outcomes
where possible. - already done. -
Make outcomes more tangible. - already done. -
Spellcheck. - already done. -
Remove/Resolve TBDs. - already done. -
EMs as informed participants in Develop and Test
. - already done. -
Iteration Strategies to its own page. - already done. -
Remove workflow::production
. - #10220 (closed) and !70391 (merged) -
Dogfood earlier? Product#1703 (closed)