Plan:Project Management
Plan: Project Management
{: #welcome}
View all team members and stable counterparts
The responsibilities of this collective team are described by the Project Management 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.
- 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.
Direction
GitLab > Dev Section > Plan Stage > Project Management Group
Performance Indicators
Customer Value
- Paid Monthly Active Users (Paid GMAU)
- Monthly Active Users
- Team Planning and Planning Analytics Category Maturity
- System Usability Score (SuS) - Decrease the count of detractors attributable to the Project Management product surface area on a rolling quarterly basis
Product Quality
- Target Error Budget of
> 99.95% - Escaped defects - The count of bug or security issues filed for defects or vulnerabilities found on canary or production on a rolling monthly basis
Process
- Open MR Age (OMA)
- Open MR Review Time (OMRT)
- Merge Request Rate - Average MRs per engineer on a rolling monthly basis
- Lead Time - The median number of days it takes for an issue to flow throw
workflow::validation backlogtoclosed. - Validation Track Cycle Time - The median number of days it takes for an issues to flow through
workflow::validation backlogtoworkflow::planning breakdown. - Build Track Phase 1 Cycle Time - The median number of days it takes for an issues to flow through
workflow::planning breakdowntoworkflow::ready for development. - Build Track Phase 2 Cycle Time - The median number of days it takes for an issues to flow through
workflow::ready for developmenttoclosed. - 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.
- Transparently: nearly everything is public, we record/livestream meetings whenever possible.
- We get a chance to work on the things we want to work on.
- Everyone can contribute; no silos.
- We do an optional, asynchronous daily stand-up in #s_plan_standup.
Capacity Planning
When we’re planning capacity for a future release, we consider the following:
- Availability of the teams during the next release. (Whether people are out of the office, or have other demands on their time coming up.)
- Work that is currently in development but not finished.
- Historical delivery (by weight) per group.
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.
Workflow
Issues and epics generally follow our 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
Project Management Boards:
Themes
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.
- A Slack channel is created with the convention #f_[feature name].
- An epic hierarchy is created with sub-epics mapping to iterations, each achievable within a milestone.
- Iterations are broken into multiple issues that can be accomplished independently, and PMs schedule those as normal.
- Other actions may be established, such as regular ‘office hours’ calls.
Team-members work together to continuously refine the iterations as complexity is revealed.
Examples of successful themes:
- Requirements Management (#f_requirements-management, Epic)
- Jira Importer (#f_jira-importer, Epic)
Talking With Customers
In a perfect world, we would have cross-functional representation in every conversation we have with customers. To help work towards realizing this, anyone who is scheduling a call with a customer via sales, conducting usabiity reasearch, or generally setting up a time to speak with customers or prospects is encouraged to add the Plan Customer Interviews 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.
Retrospectives
The Plan stage conducts [monthly retrospectives in GitLab issues][retros]. 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 project’s README.
Product Shadowing
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:
- Create an issue in the plan project tracker using the
Product-Shadowingtemplate; - Create a WIP MR to this page to update the table below, adding your name and issue link, and
- When your counterpart is assigned to the issue, add their name, remove WIP status and assign to your manager for review.
| 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 |
Speed Runs
- Labels
- Issues
b2011ea8)
