Pilot UX issue weights

The engineering team weights issues

Why do this?

Because this will allow us to better estimate capacity and give PMs a little insight into how much work we can take on in a milestone. It is less subjective and more transparent. Over time we will get better at estimating our capacity.

How will it work?

We will start in 12.10 for Growth UX, 12.11 for Enablement UX

• Jacki to add definitions of weight categories to this issue for some early discussion
• Discuss the process here
• Jacki to move discussion to an MR for more discussion and final review - gitlab-com/www-gitlab-com!42377 (diffs)
• Estimate the capacity of a designer to work on issues as part of the milestone, vs their other responsibilities such as visual reviews and Pajamas work.
• Apply weights for 12.10. Probably, we should have a synchronous planning meeting for the first milestone, so we can discuss how we are interpreting the definitions
• Hold retrospective after two months of pilot

UX Weight Definitions

Weight	Description (UX)
1	Mostly small UI changes, smaller UX improvements, without unanswered questions. No UX research, or a quick consult of existing research.
2	Simple UI or UX change where we understand all of the requirements, but may need to find solutions to known questions/problems. No UX research is planned.
3	A well-understood change but the scope of work is bigger (lots of UI or UX changes/improvements required). Multiple pages are involved, we're starting to design/redesign small flows. Some unknown questions may arise during the work. This could also be a usability study where the designer is observing sessions but not planning the research.
5	A complex change where other team members will need to be involved. Spans across multiple pages, we're working on medium-sized flows. There are significant open questions that need to be answered. This might include a UX research study where the designer is planning and conducting some research.
8	A complex change or new design that spans across large flows and may require input from other designers. This is the largest flow design/redesign that we would take on in a single milestone. This almost definitely requires research where the designer may or may not be working with a researcher.
13	A significant change that spans across multiple flows and that would require significant input from others (teams, team members, user feedback) and there are many unknown unknowns. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller Issues.

Process

• PMs will help us break issues down a little more, so we can weight a UX issue separate from an engineering issue.
  • A parent issue will use label "link::parent" and contain high level discussion and links to child issues
  • Child issues will use label "link::child" and we can create these for different parts of the product development flow. So for example, you can have a child issue for the UX work (validation and design), or you can break these down even further
• During the first milestone planning, we will use the definitions to apply weights to issues as best we can. At first we will be guessing.
• We should start weighting all our issues, this would need to be done before starting work.
• After the milestone, we need to compare what we planned with what we actually got done, and the number of person days we had to get the work done. Then we need to total the weight of the issues we got done, and use that as a baseline for the next planning period. We will aim to follow a similar process to this one.

The manage team has some info about their process - https://about.gitlab.com/handbook/engineering/development/dev/manage/#estimation

Secure and Defend team uses this spreadsheet - https://docs.google.com/spreadsheets/d/1D-ON2ix8Kk35UdmgZBOfL3haBsyXz2tvJkWi8kc7Dms/edit#gid=428417575