Changes for content/handbook/engineering/devops/plan/_index.md: 11 added lines, 52 removed lines.
Original line number
Diff line number
Diff line
@@ -11,13 +11,13 @@ Plan teams:
-[Plan:Spec-Driven Development Team](/handbook/engineering/devops/plan/spec-driven-development/)
The responsibilities of this collective team are described by the [Plan stage](/handbook/product/categories/#plan-stage). Among other things, this means
working on GitLab's functionality around issues, boards, milestones, to-do list, issue lists and filtering, roadmaps, time tracking, requirements management, notifications, value stream analytics (VSA), wiki, and pages.
working on GitLab's functionality around issues, service desk, boards, milestones, to-do list, issue lists and filtering, roadmaps, time tracking, requirements management, notifications, work plans and spec-driven development, wiki, and pages.
- I have a question. Who do I ask?
In GitLab issues, questions should start by @ mentioning the Product Manager for the [corresponding Plan stage group](/handbook/product/categories/#plan-stage). GitLab team-members can also use [#s_plan](https://gitlab.slack.com/messages/C72HPNV97).
For UX questions, @ mention the Product Designers on the Plan stage; [Nick Brandt](https://gitlab.com/nickbrandt)for Plan:Portfolio Planning. Plan:Planner Intelligence should follow the [process for groups without a designer](/handbook/product/product-processes/).
For UX questions, @ mention [Nick Brandt](https://gitlab.com/nickbrandt) or [Sunjung Park](https://gitlab.com/sunjungp), the Product Design contacts for all Plan stage groups.
### How we work
@@ -75,7 +75,7 @@ This approach offers several benefits:
1.**Single Source of Truth (SSOT)**: A design document serves as the central place for all important information related
to the initiative, reducing time spent searching for decisions across various places.
2.**Increased Visibility**: By creating design documents, we raise awareness of the work done in the
Plan stage, such as the [work items framework](../../architecture/design-documents/work_items/),
Plan stage, such as the [work items framework](../../architecture/design-documents/work_items/),[Spec-Driven Development](../../architecture/design-documents/spec_driven_development/),
[configurable Work Item Types](../../architecture/design-documents/configurable_work_item_types/), [custom fields](../../architecture/design-documents/work_items_custom_fields/), [custom status](../../architecture/design-documents/work_items_custom_status/),
[GLQL](../../architecture/design-documents/glql/), frontend-driven views, and many more.
3.**Discoverability**: Design documents are easily accessible
@@ -242,48 +242,6 @@ At specific points through the milestone the Health Status will be automatically
We feel it is important to document and communicate, that changing of any item's Health Status to "Needs Attention" or "At Risk" is not a negative action or something to be cause anxiety or concern. Raising risk early helps the team to respond and resolve problems faster and should be encouraged.
### OKRs
#### Active Quarter OKRs
FY25-Q2 Stage-level Objectives are available [here](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?sort=created_date&state=opened&label_name%5B%5D=devops%3A%3Aplan&label_name%5B%5D=division%3A%3AEngineering&not%5Blabel_name%5D%5B%5D=group%3A%3A%2a&type%5B%5D=objective&milestone_title=FY25-Q2&first_page_size=20) (internal).
#### Previous Quarter OKRs
FY25-Q1 Stage-level Objectives all closed out between 74% and 88% and are available [here](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?sort=created_date&state=closed&label_name%5B%5D=devops%3A%3Aplan&label_name%5B%5D=division%3A%3AEngineering&not%5Blabel_name%5D%5B%5D=group%3A%3A%2a&type%5B%5D=objective&milestone_title=FY25-Q1&first_page_size=20) (internal).
#### Drafting OKRs using GitLab
Guidance is available, including a video guide, on [Approach to OKRs at GitLab](/handbook/company/okrs/).
GitLab currently offers some freedom in how to structure OKR hierarchies. We take the following approach in Plan:
- EMs are encouraged to create group-level KRs under stage-level Objectives directly, without creating their own OKR structure.
- Group KRs and Stage Objectives should ladder into a higher Objective, which can exist anywhere in the organization. In the development of OKRs a stage-level Objective laddered directly into a CEO KR.
- They should be created or added as **child objectives and key results** of their parent so that progress roll-ups are visible.
- Product development goals are established in milestone planning, following the regular [Product Development Flow](/handbook/product-development/how-we-work/product-development-flow/), and not in OKRs.
Doing this ensures the hierarchy will be as simple, consistent and shallow as possible. This improves navigability and visibility, as we currently don't have good hierarchy visualization for OKRs.
An example of a valid single OKR hierarchy is:
```mermaid
flowchart TD
A[Plan Objective] --> B(Work Items KR)
A --> C[Portfolio Planning KR]
A --> D[Optimize KR]
A --> E[Planner Intelligence KR]
A --> K[Principal Engineer KR]
A --> L[SEM KR]
```
Ownership is indicated using labels and assignee(s). The label indicates the group and/or stage, assignee the DRI.
OKRs should have the following labels:
- Group, Stage, and Section (as appropriate).
- Division (~"Division::Engineering") to distinguish from other functions.
- updates::[weekly, semi-monthly, monthly] depending on how often the OKR is expected to be updated by the DRI.
### Retrospectives
The Plan stage conducts [monthly retrospectives asynchronously using GitLab issues](https://gitlab.com/groups/gl-retrospectives/plan-stage/-/issues/?label_name%5B%5D=retrospective). Monthly retrospectives are performed in a Confidential Issue made Public upon Close. Confidentiality of these Issues while Open aligns with [GitLab SAFE Framework](/handbook/legal/safe-framework/).
@@ -297,7 +255,7 @@ Retrospective issues are created by a scheduled pipeline in the
is complete with shipped and missed deliverables. For more information on how
it works, see that project's README.
Each EM is the DRI for conducting and concluding their group's retrospective, along with
For groups that run a retrospective, each EM is the DRI for conducting and concluding it, along with
summary and corrective actions.
The role of the DRI is to facilitate a psychologically safe environment where team-members
@@ -348,7 +306,7 @@ Engineering Managers are strongly encouraged to conduct a simple [Root Cause Ana
- Define corrective actions that might prevent or reduce the likelihood of a similar regression in future.
- Identify trends or patterns that can lead to human error.
The following RCA format was trialed in a FY23 Q2 OKR. It can be posted as a comment on the original MR when the regression has been successfully reverted.
The following RCA format was trialed in FY23 Q2. It can be posted as a comment on the original MR when the regression has been successfully reverted.
```markdown
**Description of the regression:**
@@ -383,7 +341,7 @@ Issues marked with this label are prioritized alongside those proposing new feat
### UX
The Plan UX team supports [Portfolio Planning](/handbook/product/categories/#portfolio-planning-group), [Work Items](/handbook/product/categories/#work-items-group) and[Planning Views](/handbook/product/categories/#planning-views-group). Portfolio Planning and Work Items are focused on the work items architecture effort. This page focuses mainly on the specifics of how we support this, since it requires alignment and cross-group collaboration.
The Plan UX team supports [Portfolio Planning](/handbook/product/categories/#portfolio-planning-group), [Work Items](/handbook/product/categories/#work-items-group),[Planning Views](/handbook/product/categories/#planning-views-group) and [Spec-Driven Development](/handbook/product/categories/#spec-driven-development-group). Portfolio Planning and Work Items are focused on the work items architecture effort. This page focuses mainly on the specifics of how we support this, since it requires alignment and cross-group collaboration.
#### UX issue management, weights and capacity planning
@@ -552,14 +510,15 @@ The meeting was removed as its functions are now covered in other ways:
Changes for content/handbook/engineering/devops/plan/spec-driven-development/_index.md: 57 added lines, 2 removed lines.
Original line number
Diff line number
Diff line
@@ -6,7 +6,51 @@ description: Engineering team page for the Plan:Spec-Driven Development group.
## Plan:Spec-Driven Development team
The Plan:Spec-Driven Development team works on
GitLab's [Spec-Driven Development](/handbook/product/categories/#spec-driven-development-group) category in the [Plan stage](/handbook/engineering/devops/plan/).
GitLab's [Spec-Driven Development group](/handbook/product/categories/#spec-driven-development-group) in the [Plan stage](/handbook/engineering/devops/plan/).
Its label is ~"group::spec-driven development" and its Slack channel is [#g_spec-driven-development](https://gitlab.slack.com/archives/g_spec-driven-development).
### Vision
Intent-to-Code is the vision for the Spec-Driven Development group. A person states what they want, and GitLab helps turn that into reviewed, working code.
Spec-driven development writes structured specifications before code and treats them as the source of truth for both people and AI. We keep the spec in the work item, so people and agents work from one source of truth for what to build, why, and how. Specs stay alive and change with the feature. The work item holds the intent, the discussion, the decisions, the plan, the status and the linked merge requests. Plan is where work is understood and agreed before code is written.
The workflow has a few steps:
- Refine the description to say what is needed and why.
- Generate a plan that says how.
- Keep a decision log.
- Resolve open questions together.
- Check that the work is ready.
- Show when an agent is working or waiting for input.
Each step can run with a person in the loop or on its own, depending on how much the team trusts the outcome.
People and agents split the work. People set the intent, the acceptance criteria and the guardrails, make the consequential decisions and own the outcome. Agents gather context, refine requirements, draft plans, write code and tests, and review the result against the plan.
This is the entry point to GitLab's Software Factory direction. Instead of people coordinating every change by hand, agents run the delivery loop and people govern it and stay in control of approvals.
### What we work on
The group owns the planning layer on work items that lets a work item be handed to an AI agent. It has no categories of its own in the product categories list.
- Workplan on work items, the plan that says how the work will be done. See the [user docs](https://docs.gitlab.com/user/work_items/workplan/).
- The decision log, a record of decisions on a work item.
- The readiness score (called the confidence score in the docs), which shows whether a plan is ready for an agent to run.
- The flow that hands a ready work item to Duo Developer and Duo Review.
### Design documents
The [design document](/handbook/engineering/architecture/design-documents/spec_driven_development/) uses the name "Agent plan" for what the product calls Workplan.
-[Work plan](/handbook/engineering/architecture/design-documents/spec_driven_development/work_plan/): the widget that stores the plan.
-[Decision log](/handbook/engineering/architecture/design-documents/spec_driven_development/decision_log/): the widget for structured decisions.
-[Scoring](/handbook/engineering/architecture/design-documents/spec_driven_development/scoring/): the readiness score.
-[Memory](/handbook/engineering/architecture/design-documents/spec_driven_development/memory/): project context and memory injected into plan generation.
-[Interactive builder](/handbook/engineering/architecture/design-documents/spec_driven_development/interactive_builder/): the Duo Chat and live preview UI for iterating on output.
-[Downstream consumers](/handbook/engineering/architecture/design-documents/spec_driven_development/downstream_consumers/): how Duo Developer and Duo Review use the plan.
-[Work item to merge request relationship](/handbook/engineering/architecture/design-documents/spec_driven_development/wi_mr_relationship/): the two-way link SDD needs.
The group shares its Engineering Manager with Plan:Work Items, so the process on the [Work Items team page](/handbook/engineering/devops/plan/work-items/) applies here. The [Plan stage page](/handbook/engineering/devops/plan/) covers the stage-wide workflow.
Changes for content/handbook/product/groups/work-items.md: 10 added lines, 55 removed lines.
Original line number
Diff line number
Diff line
@@ -6,15 +6,11 @@ title: "Plan:Work Items"
[View all team members and stable counterparts](/handbook/product/categories/#work-items-group)
The responsibilities of this collective team are described by the [Work Items Group](/handbook/product/categories/#work-items-group). Among other things, this means working on GitLab's functionality around work items, boards, milestones, iterations, to-do list, time tracking, planning analytics, and notifications.
The responsibilities of this collective team are described by the [Work Items Group](/handbook/product/categories/#work-items-group). The group owns three categories: Team Planning (issues, tasks, milestones, the to-do list, time tracking and work item types, see the [docs](https://docs.gitlab.com/topics/plan_and_track/)), Service Desk (see the [docs](https://docs.gitlab.com/user/project/service_desk/)) and Notifications (see the [docs](https://docs.gitlab.com/user/profile/notifications/)). It also owns the work items framework itself.
- I have a question. Who do I ask?
In GitLab issues, questions should start by mentioning the Product Manager (`@gweaver`). For UX questions, mention the Product Designer (`@nickleonard`). GitLab team-members can also use [#s_plan](https://gitlab.slack.com/messages/C72HPNV97).
In GitLab issues, questions should start by mentioning the Product Manager (`@gweaver`). For UX questions, @ mention [Nick Brandt](https://gitlab.com/nickbrandt) or [Sunjung Park](https://gitlab.com/sunjungp), the Product Design contacts for the Plan stage. GitLab team-members can also use [#g_work_items](https://gitlab.slack.com/archives/g_work_items).
### Performance Indicators
@@ -22,7 +18,7 @@ In GitLab issues, questions should start by mentioning the Product Manager (`@gw
-[Paid Monthly Active Users (Paid GMAU)](https://10az.online.tableau.com/#/site/gitlab/views/DRAFTCentralizedGMAUDashboard/MetricReporting/3315ab7c-ed1d-4053-bba8-cb8fc870af2b/AllGMAU?:iid=1)
-[Monthly Active Users](https://10az.online.tableau.com/#/site/gitlab/views/DRAFTCentralizedGMAUDashboard/MetricReporting/97aea9ea-11af-4f4e-8e6b-21db9738de2b/PaidGMAU?:iid=1)
- System Usability Score (SuS) - Decrease the count of detractors attributable to the Project Management product surface area on a rolling quarterly basis
- System Usability Score (SuS) - Decrease the count of detractors attributable to the Work Items product surface area on a rolling quarterly basis
#### Product Quality
@@ -40,13 +36,6 @@ In GitLab issues, questions should start by mentioning the Product Manager (`@gw
- Build Track Phase 2 Cycle Time - The median number of days it takes for an issues to flow through `workflow::ready for development` to `closed`.
- Adoption of Product Development Flow workflow labels
### History of Process Improvement Efforts
| Goal | Status | Issue |
| --------------- | ------ | ----- |
| > 90% of issues correctly reflect their current Product Development Workflow stage | In Progress | https://gitlab.com/gitlab-org/plan/-/issues/442 |
| Engineering committed issues in the current release have the `Deliverable` label applied by the 17th each month | In Progress | https://gitlab.com/gitlab-org/plan/-/issues/442 |
### How we work
- In accordance with our [GitLab values](/handbook/values/).
@@ -67,7 +56,7 @@ The first item gives us a comparison to our maximum capacity. For instance, if t
The second item is challenging and it's easy to understimate how much work is left on a given issue once it's been started, particularly if that issue is blocking other issues. We don't currently re-weight issues that carry over (to preserve the original weight), so this is fairly vague at present.
The third item tells us how we've been doing previously. If the trend is downwards, we can look to discuss this in our [retrospectives](#retrospectives).
The third item tells us how we've been doing previously. If the trend is downwards, the EM raises it in the milestone planning discussion.
Subtracting the carry over weight (item 2) from our expected capacity (the product of items 1 and 3) should tell us our capacity for the next release.
@@ -75,15 +64,10 @@ Subtracting the carry over weight (item 2) from our expected capacity (the produ
Issues and epics generally follow our [Product Development Flow](/handbook/product-development/how-we-work/product-development-flow/).
Starting in January 2022, we will be running a 3-6 month experiment to shift the planning cadence from milestones to iterations with the primary goal of planning in smaller batches to enable more timely, better decision making. Iteration planning will take place via our 30 minute weekly Engineering/Product/UX sync. Only issues that have been weighted and marked as `~workflow::ready for development` will be scheduled into upcoming iterations. While we will be leveraging iterations, we will still follow our documented [product development timeline](/handbook/engineering/workflow/#product-development-timeline)
@@ -107,35 +91,6 @@ In a perfect world, we would have cross-functional representation in every conve
You can subscribe to the calendar and invite it as a participant in a customer meeting that you are scheduling using the URL [gitlab.com_5icpbg534ot25ujlo58hr05jd0@group.calendar.google.com](mailto:gitlab.com_5icpbg534ot25ujlo58hr05jd0@group.calendar.google.com).
#### Retrospectives
The Plan stage conducts monthly retrospectives in GitLab issues.
These are confidential during the initial discussion,
then made public in time for each month's [GitLab retrospective]. For
more information, see [team retrospectives].
The retrospective issue is created by a scheduled pipeline in the
[async-retrospectives] project. For more information on how it works, see that
Engineering team-members can shadow a product stable-counterpart. Shadowing sessions last two working days, or the equivalent split over multiple days to maximize experience with different functions of the role. To shadow a counterpart on the team:
1. Create an issue in the [plan](https://gitlab.com/gitlab-org/plan) project tracker using the `Product-Shadowing` template;
1. Create a WIP MR to this page to update the table below, adding your name and issue link, and
1. When your counterpart is assigned to the issue, add their name, remove WIP status and assign to your manager for review.
