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.
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.
GitLab > Dev Section > Plan Stage > Project Management Group
> 99.95%
workflow::validation backlog
to closed
.workflow::validation backlog
to workflow::planning breakdown
.workflow::planning breakdown
to workflow::ready for development
.workflow::ready for development
to closed
.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 |
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.
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:
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. 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.
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.
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:
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 |