Plan:Work Items

Plan: Work Items

View all team members and stable counterparts

The responsibilities of this collective team are described by the 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), Service Desk (see the docs) and Notifications (see the docs). 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 Nick Brandt or Sunjung Park, the Product Design contacts for the Plan stage. GitLab team-members can also use #g_work_items.

Performance Indicators

Customer Value

• Paid Monthly Active Users (Paid GMAU)
• Monthly Active Users
• System Usability Score (SuS) - Decrease the count of detractors attributable to the Work Items 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 backlog to closed.
• Validation Track Cycle Time - The median number of days it takes for an issues to flow through workflow::validation backlog to workflow::planning breakdown.
• Build Track Phase 1 Cycle Time - The median number of days it takes for an issues to flow through workflow::planning breakdown to workflow::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 development to closed.
• Adoption of Product Development Flow workflow labels

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:

1. Availability of the teams during the next release. (Whether people are out of the office, or have other demands on their time coming up.)
2. Work that is currently in development but not finished.
3. 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, 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.

Workflow

Issues and epics generally follow our Product Development Flow.

Work Items issue lists:

• Issues labeled group::work items
• Same list, current milestone

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 themes broken down this way:

1. Configurable statuses (Epic)
2. Custom fields (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.

Speed Runs

• Labels
  • Scoped Labels
• Issues
  • Description Change History