The responsibilities of this collective team are described by the Plan stage. Among other things, this means working on GitLab's functionality around issues, issue boards, milestones, to-do list, issue lists and filtering, roadmaps, time tracking, requirements management, and notifications.
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.
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 -
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. 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 firstname.lastname@example.org.
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. Some of these issues use supplemental boards:
Other issues just define that, for instance, anything in or to the left of ~"workflow::ready for development" should be moved as a milestone comes to a close. 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, Product and Engineering Managers will assign the 'On Track' status to agreed-upon priority issues. As the Milestone progresses, anyone contributing to the work should update the 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".
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.
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 project's README.
Most of our group meetings are recorded and publicly available on YouTube in the Plan group playlist.
We hold a weekly team meeting where all team members across all functions are invited. We currently alternate the meeting time each week to be inclusive of our distributed team. The meeting is either EMEA (+Eastern US) friendly or APAC (+Western US) friendly. Regardless of the timezone we always record each meeting and post it to our youtube playlist.
The agenda follows this format:
If there are no agenda items eight hours prior to the call, we skip the call entirely.
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:
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:
|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|