Our priorities should follow [overall guidance for Product](/handbook/product/product-processes/). This should be reflected in the priority label for scheduled issues:
Our priorities should follow [overall guidance for Product](/handbook/product/product-processes/). This should be reflected in the priority label on each issue. **Engineers are the DRI for assigning priority labels** to the issues they work on, ensuring visibility into the relative importance of work across the team.
| Priority | Description | Probability of shipping in milestone |
| ------ | ------ | ------ |
@@ -104,12 +104,9 @@ flowchart TB
#### Organizing the work
We generally follow the [Product Development Flow](/handbook/product-development/how-we-work/product-development-flow/#workflow-summary):
We generally follow the [Product Development Flow](/handbook/product-development/how-we-work/product-development-flow/#workflow-summary). As an engineering team, we focus on the following workflow stages:
1.`workflow::problem validation` - needs clarity on the problem to solve
1.`workflow::design` - needs a clear proposal (and mockups for any visual aspects)
1.`workflow::solution validation` - needs refinement and acceptance from engineering
1.`workflow::planning breakdown` - needs a Weight estimate
1.`workflow::planning breakdown` - needs a Weight estimate. **The engineer who opens an issue is the DRI for moving it from this stage to `workflow::ready for development`.**
1.`workflow::scheduling` - needs a milestone assignment
1.`workflow::ready for development`
1.`workflow::in dev`
@@ -117,6 +114,8 @@ We generally follow the [Product Development Flow](/handbook/product-development
1.`workflow::verification` - code is in production and pending verification by the DRI engineer
1.`workflow::complete` - the code has been verified and the work is complete, issue should be closed
Discovery work (problem validation, design, solution validation) is handled separately in dedicated discovery issues, epics, or prototypes rather than as required steps for every issue.
Generally speaking, issues are in one of two states:
- Discovery/refinement: we're still answering questions that prevent us from starting development,
@@ -235,19 +234,17 @@ Once an issue has been estimated, it can then be moved to `workflow::scheduling`
#### Planning
We plan in monthly cycles in accordance with our [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline). Meeting this timeline is up to the discretion of individual groups. A typical Optimize planning cycle looks like:
Engineers are the DRI for their own work. Rather than a top-down milestone cadence driven by the EM and PM, engineers are expected to work autonomously to deliver on the team's roadmap by self-managing the process of creating issues, estimating them, and assigning themselves work.
The guiding principles for how we work are:
-**Speed with quality** — deliver fast without compromising on standards.
-**Ownership mindset** — engineers own outcomes, not just tasks.
-**Customer outcomes** — every piece of work should connect to a customer benefit.
Engineers are expected to delegate as much implementation work as possible to AI agents, acting as close to a [Level 3 engineer](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/) as possible — orchestrating delivery rather than executing every task manually.
- By the 4th, Product should have created a planning issue for their group in the [Optimize Group Admin project](https://gitlab.com/gitlab-org/analytics-section/optimize-group/admin/-/issues) for the coming release.
- This issue should include a tentative plan for the release, along with links to boards that represent the proposed work for the milestone.
- A board filtered by the `Next 1 - 3 releases` milestone is used to caputure upcoming issues.
- Issues of particular significance to our stage's strategy should be marked with `direction`.
- By the 12th, all issues proposed for the next release should be estimated with weights assigned by engineering (`workflow:ready for development`).
- To assist with capacity planning, we start with a capacity of 10 weight per engineer and deduct based on time off, team days, on-call schedules, or other activities. The EM captures the execpted capacity in the planning issue.
- Issues that we know will slip from the previous release should be reweighted for the remaining effort left and rescheduled to the next release.
- By the 15th, Product and Engineering will have ordered the list of issues in the `Next 1 - 3 releases` board.
- Depending on availibility, either Product or Engineering will take capacity into consideration and assign the top issues in each type category to the next release.
- The engineering manager will assign the ~Deliverable label to any committed work.
- The entire planning process is asynchronous, however a synchronous meeting to review the final release scope is optional if Product and Engineering require additional collaboration.
Milestones are used to communicate to customers what is available in any given version of GitLab, to schedule complex multi-version features, and to help estimate what the team can achieve in a given quarter. They should not dictate the pace of delivery or slow engineers down.
##### Deliverable and Stretch issues
@@ -271,19 +268,24 @@ If a community member expresses interest in taking on an issue, a relevant Optim
##### Self assignment
During planning, the EM may assign issues to individual engineers when it makes sense, but in general the issues will remain unassigned and left for engineers to self assign once planning has been finalized.
Self-assignment is the default and primary mode of working. Engineers proactively identify work that aligns with the team's roadmap and assign it to themselves — there is no dependency on the EM or PM to assign work.
Expectations by role:
Expectations:
- EM to ping engineers on the planning issue once finalized.
- Engineers to self assign issues before the start of the release.
- EM to highlight unassigned issues during weekly team call.
- Engineers self-assign issues as they pick up work, keeping their assignment up to date at all times.
- Engineers are responsible for ensuring the issues they work on are well-defined, estimated, and correctly labelled before beginning development.
- EM to highlight unassigned issues during the weekly team call to ensure nothing falls through the cracks.
#### During a release
- When an issue is introduced into a release after Kickoff, an equal amount of weight must be removed to account for the unplanned work.
- Development should not begin on an issue before it's been estimated and given a weight.
- By the 15th, engineering merge requests should be merged. In other words, we assume code merged after the 15th will not be in the release. That allows time for the release to be finalized, and any associated [Release Posts](/handbook/marketing/blog/release-posts/) to be merged by the 17th. (This is an [experiment starting with 13.11](https://gitlab.com/gitlab-org/manage/general-discussion/-/issues/17330).)
Engineers are expected to actively and transparently communicate progress on a **weekly cadence** throughout a release. Each weekly update should cover:
-**Done** — what was completed in the past week.
-**In progress** — what is currently being worked on.
-**Coming up** — what is planned for the week ahead.
-**Challenges / blockers** — any impediments that are slowing down or blocking progress.
The format of this communication may vary per project or feature, but the standard location for these updates is the **high-level epic** related to the project or feature being worked on. This ensures stakeholders have a single place to follow progress without needing to chase status updates.
