Plan teams:
The responsibilities of this collective team are described by the 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.
In GitLab issues, questions should start by @ mentioning the Product Manager for the corresponding Plan stage group. GitLab team-members can also use #s_plan.
For UX questions, @ mention the Product Designers on the Plan stage; Nick Leonard for Plan:Project Management, Nick Brandt for Plan:Product Planning, and Libor Vanc for Plan:Optimize. Plan:Knowledge should follow the process for groups without a designer.
We work in a continuous Kanban manner while still aligning with Milestones and GitLab's Product Development Flow.
When we're planning capacity for a future release, we consider the following:
The first item gives us a comparison to our maximum capacity. For instance, if the team has four people, and one of them is taking half the month off, then we can say the team has 87.5% (7/8) of its maximum capacity.
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.
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.
Points of weight delivered by the team in previous milestones, including a 3-month rolling average, are available in this chart. This allows for more accurate estimation of what we can deliver in future milestones.
Issues have the following lifecycle. The colored circles above each workflow stage represents the emphasis we place on collaborating across the entire lifecycle of an issue; and that disciplines will naturally have differing levels of effort required dependent upon where the issue is in the process. If you have suggestions for improving this illustration, you can leave comments directly on the whimsical diagram.
Everyone is encouraged to move issues to different workflows if they feel they belong somewhere else. In order to keep issues constantly refined, when moving an issue to a different workflow stage, please review any open discussions within the issue and update the description with any decisions that have been made. This ensures that descriptions are laid out clearly, keeping with our value of Transparency.
If an issue is > 3 weight, it should be promoted to an epic (quick action) and split it up into multiple issues. It's helpful to add a task list with each task representing a vertical feature slice (MVC) on the newly promoted Epic. This enables us to practice "Just In Time Planning" by creating new issues from the task list as there is space downstream for implementation. When creating new vertical feature slices from an epic, please remember to add the appropriate labels - devops::plan, group::*, Category:* or feature label, and the appropriate workflow stage label - and attach all of the stories that represent the larger epic. This will help capture the larger effort on the roadmap and make it easier to schedule.
A small number of high priority features will be chosen as 'themes' for a period of time. Themes provide an opportunity for the whole team to rally around a deliverable, even if they don't contribute directly to it. These items are given especially close attention by all those involved with a view to delivering small iterations and keeping work unblocked. There should never be more than two themes in progress at a time per team.
Team-members work together to continuously refine the iterations as complexity is revealed.
Examples of successful themes:
In a perfect world, we would have cross-functional representation in every conversation we have with customers.
Anyone who is scheduling a call with a customer via sales, conducting usability reasearch, or generally setting up a time to speak with customers or prospects is encouraged to add the Plan Customer Conversations calender as an invitee to the event. This will automatically populate the shared calendar with upcoming customer and user iteractions. All team members are welcome and encouraged to join – even if it's just to listen in and get context.
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.
All team members are welcome and encouraged to join customer calls – even if it's just to listen in and get context.
To ensure upcoming calls appear in your calendar, subscribe to the Plan Customer Conversations calendar. Product Managers add upcoming customer interviews to this calendar and you're welcome to shadow any call.
Upcoming customer calls will often be advertised in the #s_plan channel in advance, so look out there also.
All recorded customer calls, with consent of the customer, are made available for Plan team-members to view in Dovetail.
To access these, simply go to the Plan Customer Calls project on Dovetail and log in with Google SSO. More information is available in the Readme of this project.
If you find you do not have access, reach out to a Plan PM and ask to be added as a Viewer.
We perform many board refinement tasks asynchronously, using GitLab issues in the Plan project. The policies for these issues are defined in triage-ops/policies/plan-stage. A full list of refinement issues is available by filtering by the ~"Plan stage refinement" label.
While we operate in a continuous Kanban manner, we want to be able to report on and communicate if an issue or epic is on track to be completed by a Milestone's due date. To provide insight and clarity on status we will leverage Issue/Epic Health Status on priority issues.
At the beginning of the Milestone, Deliverable issues will automatically be updated to "On Track". As the Milestone progresses, assignees should update Health Status as appropriate to surface risk or concerns as quickly as possible, and to jumpstart collaboration on getting an issue back to "On Track".
At specific points through the milestone the Health Status will be automatically degraded if the issue fails to progress. Assignees can override this setting any time if they disagree. The policy that manages this automation is here. It can be disabled for any individual issue by adding the ~"Untrack Health Status" label.
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.
FY24-Q4 Stage-level Objectives are available here.
FY24-Q3 Stage-level Objectives are available here (internal).
In addition, Plan groups had KRs supporting an Objective to Reach a 50% minimum of pajamas compliance for dropdowns in Q3:
Guidance is available, including a video guide, on how to use GitLab for OKRs.
GitLab currently offers some freedom in how to structure OKR hierarchies. We take the following approach in Plan:
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:
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:
The Plan stage conducts monthly retrospectives asynchronously using GitLab issues. Monthly retrospectives are performed in a Confidential Issue made Public upon Close. Confidentiality of these Issues while Open aligns with GitLab SAFE Framework.
The Plan Stage team encourages the use of Internal Notes as well to further adhere to SAFE Guidelines. Internal notes remain confidential to participants of the retrospective even after the issue is made public, including Guest users of the parent group. Dogfooding this feature aligns with an FY23 Q4 OKR of improving the GitLab Product development flow by driving the adoption of Plan features.
Examples of information that should remain Confidential per SAFE guidelines are any company confidential information that is not public, any data that reveals information not generally known or not available externally which may be considered sensitive information, and material non-public information.
The retrospective issue is created by a scheduled pipeline in the async-retrospectives project. It is then updated once the milestone is complete with shipped and missed deliverables. For more information on how it works, see that project's README.
An EM from the Plan stage is assigned to each retrospective on a rotational basis as the DRI for conducting and concluding the retrospective, along with summary and corrective actions. The rotation for upcoming milestones is as follows:
| Milestone | DRI |
|---|---|
| 16.6 | Donald Cook |
| 16.7 | Kushal Pandya |
| 16.8 | John Hope |
| 16.9 | Brandon Labuschagne |
| 16.10 | Donald Cook |
| 16.11 | Kushal Pandya |
The role of the DRI is to facilitate a psychologically safe environment where team-members feel empowered to give feedback with candour. As such they should refrain from participating directly. Instead they should publicise, conclude and make improvements to the retrospective process itself.
To improve the retrospective data-driven experience, we are dogfooding VSA to simplify the data collection for the retrospective. This been done by automatically adding a link to the VSA of the current milestone filtered by group/stage to the retrospective. With Value stream analytics (VSA) our team is getting visibility to the lifecycle metrics of each milestone through the breakdown of the end-to-end workflow into stages. This allows us to identify bottlenecks and take action to optimize actual flow of work.
For example, for the review phase, we are using VSA to count the time between "workflow::in review" and "MR merged". With this data, we can identify:
same-team MR reviews or out-of-team MR reviews.Please leave your feedback in this issue.
The DRI is responsible for completing the following actions:
gl-retrospectives/plan for each is optional, but doing so and adding the ~"follow-up" label will ensure they're included automatically in the next retrospective.In both the summary comment and video the DRI should be particularly careful to ensure all information disclosed is SAFE. If the retrospective discussion contains examples of unSAFE information, the issue should not be made public.
Regressions contribute to the impression that the product is brittle and unreliable. They are a form of waste, requiring the original (lost) effort to be compounded further with a fix or a reversion and reimplementation of the intended behavior.
Engineering Managers are strongly encouraged to conduct a simple Root Cause Analysis (RCA) when a regression takes place in a feature owned by their group, in order to:
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.
**Description of the regression:**
_One-line description of the regression in behavior._
**Bug report:** _[Issue link]_
`@author`` (if internal) `@approvers` Please could you reply to this comment, copying the questions below and giving some short answers?
1. Were you aware this MR was reverted in the course of your normal work (e.g. through email notification, general work process)?
1. Did you identify the problematic behavior before approving this MR?
1. If not, what would've made the regression more obvious during review?
1. What changes to our tooling or review process would have prevented this regression from being merged?
1. Were the steps to test the MR mentioned clearly in the description? Were they easy to follow?
1. Do you have any other comments/suggestions?
Please reassure the participants that the purpose is not to apportion blame but to gather data, identify causal factors and implement corrective actions - but ask for a swift and brief response while the information is still fresh.
The UX Paper Cuts team has a dedicated role addressing Paper Cuts concerns within the Plan stage.
The UX Paper Cuts team member covering Plan will regularly triage the list of UX Paper Cuts issues that are related to the Plan stage as outlined above, but will also add actionable candidates to a Plan-specific epic for transparency.
Triaged Plan-specific Paper Cuts issues can be found in https://gitlab.com/groups/gitlab-org/-/epics/12061. Currently, quarterly child epics will be created under that parent epic to organize work.
See further details at https://handbook.gitlab.com/handbook/product/ux/product-designer/#suggesting-paper-cuts-to-the-team
There are many company, team, process (and other) updates that are important to communicate to team members so that they are not missed. Besides that, there is other information important for day-to-day work. In Plan we use async Weekly updates, called Plan Weekly digest, to communicate these to our team members.
The Engineering Managers in the Plan stage alternate each week as the DRIs. There are 4 groups in the Plan stage, and one SEM, so every EM is the DRI roughly once / 5 weeks.
The responsibility of the DRI is simply to collect information and to ensure the issue is ready to be publicized in time for the coming week. All team-members are welcome to participate in suggesting content using discussions or adding it directly by editing the description.
| Issue creation (auto) | DRI |
|---|---|
| 2023-11-20 | Kushal Pandya |
| 2023-11-27 | Brandon Labuschagne |
| 2023-12-04 | Donald Cook |
| 2023-12-11 | John Hope |
| 2023-12-18 | Donald Cook |
| 2023-12-25 | John Hope |
| 2024-01-01 | Kushal Pandya |
| 2024-01-08 | John Hope |
Most of our group meetings are recorded and publicly available on YouTube in the Plan group playlist.
Plan held a weekly team-meeting as a stage until 2023-11-01. The agenda is still available.
The meeting was removed as its functions are now covered in other ways:
~group::project management
~group::product planning
~group::optimize
~group::knowledge
There is a shared Plan stage calendar which is used for visibility into meetings within the stage.
c_b72023177f018d631c852ed1e8[email protected] into the form and hit enter.Plan Shared as a guest.Team Days are organized on a semi-regular basis. During these events we take time to celebrate wins since the last team day, connect with each other in remote social activities, and have fun!
Anyone can organize a team day. It starts with creating a Team Day planning issue in the plan-stage tracker and then proceeding to find a suitable date.
A time-boxed vote no more than 3 months but no less than 1 month out has proven to be the most inclusive way to set a date so far. This allows enough time to organize sessions but is usually close enough to avoid colliding with off-sites, or other company-wide activities.
Including at least three major timezones, one for each of AMER, EMEA, and APAC, in the issue description allows people to better see how the day will be divided for them and what they can attend.
It's good practice to rotate the 'base' timezone of the Team Day to spread the opportunity for attendance. For example; the FY23-Q4 Team Day was based on a full UTC day, the FY24-Q3 on a full day AEST.
The day is composed of sessions proposed and organized by team-members. These are typically allocated 1hr, though they can be longer or shorter. Sessions can be scheduled in advance to allow other team-members to plan their attendance and participation.
Sessions can be anything really, so long as it aligns with the values. Team-members can organize a game, teach a skill, give a talk on something they know, or anything else they think others might enjoy.
Some examples of sessions we've had on previous team days include:
Free time slots can be used on the day to hold impromptu events requiring little or no preparation.
Participation in team day is encouraged for any team-member or stable counterpart in Plan. If you collaborate with Plan team-members on a regular basis you're also very welcome to attend.
Participating team-members are encouraged to drop non-essential work and take part in any sessions during the day that they wish to. Those assigned to essential work; such as critical bugs, incidents, or IMOC shifts, are encouraged to participate between their other obligations.
Team day is a normal workday for those choosing not to participate.
Some sessions may require small purchases to participate fully; for example, ingredients for a cooking class or hosting of a private video game server.
Unless communicated in advance these are not expensable.
The DRI for organizing Team Day may pursue a budget for expenses under existing budgets; such as the team building budget, or fun budget. If successful it should be made clear to team-members well in advance:
Each group within the Plan stage follows GitLab's product development flow and process. This allows for consistency across the stage, enables us to align with other stages and stable-counterparts, and enables us to clearly understand our throughput and velocity. We're currently focused on strictly following the process stated in the handbook, as opposed to creating our own local optimizations.
In some cases we need to dogfood a new Plan feature that may adjust our adherence to the GitLab's process. If that happens we assign a DRI responsible for setting the objective, reporting on the outcomes and facilitating feedback to ensure we prioritize improvements to our own product. This ensures we're not making a change for the sake of making changes, and gives us clarity into our own evaluation of a change to the product. In some cases we need to dogfood a new Plan feature that may adjust our adherence to the GitLab's process. If that happens we assign a DRI responsible for setting the objective, reporting on the outcomes and facilitating feedback to ensure we prioritize improvements to our own product. This ensures we're not making a change for the sake of making changes, and gives us clarity into our own evaluation of a change to the product.
There are a couple of process-related improvements we'll continue to adopt:
Like all groups at GitLab, a working group is an arrangement of people from different functions. What makes a working group unique is that it has defined roles and responsibilities, and is tasked with achieving a high-impact business goal fast. A working group disbands when the goal is achieved (defined by exit criteria) so that GitLab doesn’t accrue bureaucracy.
Stage Working Groups are focused on initiatives that require collaboration between multiple groups within the stage. The structure of stage working groups is similar to company-wide working groups, with DRI and well-defined roles. The initiatives are driven by a stage-level product direction rather than an Executive Sponsor, and can be formed of just Functional Leads and members who participate in fulfilling the exit criteria.
There can be a gap in understanding between Engineering and Product on a team. We are experimenting with a pilot programme that will allow engineers to spend time in the world of Product, with the goal of greater mutual communication, understanding and collaboration. It helps us work more effectively as a team for better features.
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. In particular, the session should include at least one customer call. To shadow a counterpart on the team:
Product-Shadowing template;| Month | Engineering counterpart | Product counterpart | Issue link |
|---|---|---|---|
| 2020-07 | Charlie Ablett (@cablett) | Keanon O'Keefe (@kokeefe) | gitlab-org/plan#118 |
| 2020-10 | Jan Provaznik (@jprovaznik) | Gabe Weaver (@gweaver) | gitlab-org/plan#185 |
We're tracking a number of issues that we believe could cause scalability problems in the future.
| Type | Description | Estimated Timeline for Failure | Resolution Due Date | 12 Month Target | Issue | Status |
|---|---|---|---|---|---|---|
| Primary key int4 overflow | system_note_metadata.id column is at 50% saturation and must be converted to bigint (int8). |
March 2024 - 2025 | 2023-12-22 | Sub-50% | #424114 | Urgent |
| Redis Primary CPU | Unexpected load on the Shared State Redis instance caused by SUBSCRIBE, UNSUBSCRIBE and PUBLISH commands. |
Unknown | November 2023 | 150k Concurrent WebSocket Connections at peak | Okay | |
| Redis Memory | Retention of Action Cable messages in Redis Shared State memory due to high numbers of and/or stalled/hung clients. | Unknown | November 2023 | 150k Concurrent WebSocket Connections at peak | #326364 | Okay |
| Various | Scaling a combined 'Work Items' table consisting of all current issues, epics, requirements and test cases. | Unknown | November 2023 | 100k Work Items created per day | Okay |
Note: Work is ongoing on migration helpers to mitigate Int4 Primary Key Overflows. These will provide a standard way to resolve these issues.