Fix broken links in product

| 8 | A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements. |

| 13| A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller Issues. |

In planning and estimation, we value [velocity over predictability](/handbook/engineering/development/principles/#velocity-over-predictability). The main goal of our planning and estimation is to focus on the [MVC](/handbook/values/#minimal-valuable-change-mvc), uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. In general departments at GitLab aim for [70% predictability] but in the Fulfillment sub-department we aim for 80% predictability since our work is typically cross-functional and we need to be in lockstep with other departments.

In planning and estimation, we value [velocity over predictability](/handbook/engineering/development/principles/#velocity). The main goal of our planning and estimation is to focus on the [MVC](/handbook/values/#minimal-valuable-change-mvc), uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. In general departments at GitLab aim for [70% predictability] but in the Fulfillment sub-department we aim for 80% predictability since our work is typically cross-functional and we need to be in lockstep with other departments.

- If an issue has many unknowns where it's unclear if it's a 1 or a 5, we will be cautious and estimate high (5).

- If an issue has many unknowns, we can break it into two issues. The first issue is for research, also referred to as a [Spike](https://en.wikipedia.org/wiki/Spike_(software_development)), where we de-risk the unknowns and explore potential solutions. The second issue is for the implementation.

1. We [cut scope](/handbook/values/#move-fast-by-shipping-the-minimal-valuable-change).

1. We miss the due date.

Only the last two outcomes are acceptable as a general rule. Missing a 'due date' in the form of an assigned milestone is often OK as we put [velocity above predictability](/handbook/engineering/development/principles/#the-importance-of-velocity), and missing the monthly self-managed release does not prevent code from reaching GitLab.com.

Only the last two outcomes are acceptable as a general rule. Missing a 'due date' in the form of an assigned milestone is often OK as we put [velocity above predictability](/handbook/engineering/development/principles/#velocity), and missing the monthly self-managed release does not prevent code from reaching GitLab.com.

For these reasons, and others, we intentionally [do not define a specific date](/handbook/engineering/releases/monthly-releases#timelines) for code to be merged in order to reach a self-managed monthly release. The earlier it is merged, the better. This also means that:

- [backend](https://docs.gitlab.com/ee/development/api_graphql_styleguide.html)

- [frontend](https://docs.gitlab.com/ee/development/fe_guide/graphql.html)

- [use GraphQL everywhere](https://gitlab.com/groups/gitlab-org/-/epics/1366)

- [the importance of velocity](/handbook/engineering/development/principles/#the-importance-of-velocity)

- [the importance of velocity](/handbook/engineering/development/principles/#velocity)

- [engineering proposed initiative](/handbook/engineering/#engineering-proposed-initiatives)

| 8 | A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements. |

| 13| A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller Issues. |

In planning and estimation, we value [velocity over predictability](/handbook/engineering/development/principles/#velocity-over-predictability). The main goal of our planning and estimation is to focus on the [MVC](/handbook/values/#minimal-valuable-change-mvc), uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. We aim for 70% predictability instead of 90%. We believe that optimizing for velocity (merge request rate) enables our Growth teams to achieve a [weekly experimentation cadence](/handbook/product/groups/growth/#weekly-growth-meeting).

In planning and estimation, we value [velocity over predictability](/handbook/engineering/development/principles/#velocity). The main goal of our planning and estimation is to focus on the [MVC](/handbook/values/#minimal-valuable-change-mvc), uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. We aim for 70% predictability instead of 90%. We believe that optimizing for velocity (merge request rate) enables our Growth teams to achieve a [weekly experimentation cadence](/handbook/product/groups/growth/#weekly-growth-meeting).

- If an issue has many unknowns where it's unclear if it's a 1 or a 5, we will be cautious and estimate high (5).

- If an issue has many unknowns, we can break it into two issues. The first issue is for research, also referred to as a [Spike](https://en.wikipedia.org/wiki/Spike_(software_development)), where we de-risk the unknowns and explore potential solutions. The second issue is for the implementation.

Below is a guide to help other product groups understand how to work on these areas and quickly locate the best parties who may assist on the subject matter.

This section is modeled after the engineering handbook version of [ownership of shared services and components](/handbook/engineering/development/#ownership-of-shared-services-and-components).

This section is modeled after the engineering handbook version of [ownership of shared services and components](/handbook/company/infrastructure-standards/realms/infra-shared-services/).

### Existing Cross-Stage Capabilities

The resources in the Product L & D Hub are meant to support product managers to explore, learn and grow at their own pace. We aim to collect content that spans various skill levels, as well as various levels of depth/commitment. It is recommended that product managers engage with the resources here to help them have a successful journey at GitLab and in their product career as a whole.

Most of the resources here are free but any content requiring payment [can be reimbursed following the GitLab reimbursement policies](/handbook/finance/expenses/#work-related-online-courses-and-professional-development-certifications).

Most of the resources here are free but any content requiring payment [can be reimbursed following the GitLab reimbursement policies](/handbook/people-group/learning-and-development/growth-and-development/).

Over time, we will add content to directly support GitLab's product management [competencies](/handbook/product/product-management/product-cdf-competencies/), [CDF](/handbook/product/product-management/product-cdf-competencies/) and [product development flow](/handbook/product-development/how-we-work/product-development-flow/). We understand that the evolving product management space requires continuous learning, and GitLab is committed to providing the time needed for in-depth learning too as part of your working time. You are encouraged to ask your manager to help you carve out time for Learning and Development.