Changes for content/handbook/engineering/devops/plan/project-management.md: 1 added line, 1 removed line.
Original line number
Diff line number
Diff line
@@ -53,7 +53,7 @@ To help drive alignment with our stable counterparts, provide visibility into pr
- Feature (Epic) - Contains all the necessary vertical feature slices to default the corresponding feature flag to "on". The feature epic will also serve as the location to generate a corresponding Release Post item MR. The feature epic should be scoped to the [minimal amount of functionality that still provides customer value](/handbook/product/product-principles/#the-minimal-valuable-change-mvc). Additional scope planned for future enhancements should be stored in follow-on epics.
- Spike (Issue) - If we are unable to accurately estimate the effort necessary to implement the feature, we first conduct a spike
- UX (Issue) - For larger initiatives, UX creates a separate UX issue that serves as the SSOT for design goals, design drafts, design conversation and critique, and the chosen design direction that will be implemented. [Learn more about UX issues](/handbook/product/ux/product-design/ux-roadmaps/).
- UX (Issue) - For larger initiatives, UX creates a separate UX issue that serves as the SSOT for design goals, design drafts, design conversation and critique, and the chosen design direction that will be implemented. [Learn more about UX issues](/handbook/upstream-studios/product-design/ux-themes/).
- Vertical Feature Slice (Issue) - A subset of the feature that can be completed within a single milestone, tested, and verified within the `plan-stage` group on production.
- Engineering Tasks (Task - *Optional*) - One or more engineering tasks that need to be completed in order to deliver the vertical feature slice. The scope of a task should generally correlate to a single MR.
Changes for content/handbook/product/cross-stage-features/work-items.md: 2 added lines, 2 removed lines.
Original line number
Diff line number
Diff line
@@ -39,7 +39,7 @@ You can see new functionality planned in the [Plan stage direction page](https:/
## Getting started
First, you will need to consider whether the work items framework is right for your feature, including your users and the experience they require. You can read about that process [here](/handbook/product/ux/product-design/ux-roadmaps/).
First, you will need to consider whether the work items framework is right for your feature, including your users and the experience they require. You can read about that process [here](/handbook/upstream-studios/product-design/ux-themes/).
All contributions begin with the _Validation backlog_ and _Problem validation_ phases. During these phases, the Plan stage PMs should be **Informed** of upcoming validation activities and **Consulted** during problem validation. These are critical opportunities to collaborate with us and ensure that your ask is not overlapping with future roadmap items and is not against the guiding principles.
@@ -54,7 +54,7 @@ At the end of this phase, we will work with your group to determine a contributi
## Contribution models
If you decide to use the work items framework this will usually mean that you're creating a new work item type and/or creating new widgets. Sometimes, all functionality you need will already be in the framework. Hooray! If not, you can contribute to the framework to [extend it for your use case](/handbook/product/ux/product-design/ux-roadmaps/).
If you decide to use the work items framework this will usually mean that you're creating a new work item type and/or creating new widgets. Sometimes, all functionality you need will already be in the framework. Hooray! If not, you can contribute to the framework to [extend it for your use case](/handbook/upstream-studios/product-design/ux-themes/).
Changes for content/handbook/product/product-processes/_index.md: 1 added line, 1 removed line.
Original line number
Diff line number
Diff line
@@ -649,7 +649,7 @@ You should link to your category strategy from your stage strategy page.
For categories that have already shipped, and that have a marketing
product page, `categories.yml` should link to the product page.
If the category has developed a [UX Roadmap](/handbook/product/ux/product-design/ux-roadmaps/) we recommend the product designer to create a merge request to incorporate UX Roadmap themes into the category direction page roadmap. Assign the MR to the PM for review and merge.
If the category has developed a [UX Roadmap](/handbook/upstream-studios/product-design/ux-themes/) we recommend the product designer to create a merge request to incorporate UX Roadmap themes into the category direction page roadmap. Assign the MR to the PM for review and merge.
##### Navigating cross-stage or cross-section direction pages
Changes for content/handbook/product/ux/jobs-to-be-done/jtbd-beyond-the-playbook.md: 1 added line, 1 removed line.
Original line number
Diff line number
Diff line
@@ -16,7 +16,7 @@ For example: Say we have a study that needs security professionals using the vul
Using [GitLab's list](/handbook/product/personas/#list-of-user-personas) of user personas, we could create a list of job titles used by security personas to generate a list of more than 10 titles, such as Security Analyst, Security Operation Engineer, Security Consultant, Application Security Engineer, etc. This list would be very cumbersome for a respondent to answer and may not reflect the accurate day-to-day role of your ideal candidate.
Using the [JTBD for the Secure and Software Supply Chain Security](/handbook/product/ux/product-design/ux-roadmaps/) stages, we could identify two or three ideal jobs/job performers for our study. Look at these job statements for example: "I identify risk in my org's assets" and "I address detected business-critical vulnerabilities." Additionally, we can include jobs from other workflows in the Secure section if we want to include invalid options to weed out unfit candidates. This screener question would be a handful of options that participants can select, and the result is a participant that accurately reflects your ideal candidate.
Using the [JTBD for the Secure and Software Supply Chain Security](/handbook/upstream-studios/product-design/ux-themes/) stages, we could identify two or three ideal jobs/job performers for our study. Look at these job statements for example: "I identify risk in my org's assets" and "I address detected business-critical vulnerabilities." Additionally, we can include jobs from other workflows in the Secure section if we want to include invalid options to weed out unfit candidates. This screener question would be a handful of options that participants can select, and the result is a participant that accurately reflects your ideal candidate.
To make it easier, you can save all of the main jobs for your stage as a template and allow only selected ones for each study you have, like in [this example](https://docs.google.com/document/d/1317XpsPeRBdpMb3rrVnPPPSR90xVyiWAJI6IZsot3PM/edit?usp=sharing). If participants do not match their main job, that can signal you to go back and accurately check how you [discovered your JTBD](/handbook/product/ux/jobs-to-be-done/#how-do-i-discover-jtbd-relevant-to-my-group).