The responsibilities of this stage are described by the Manage product category. Manage is made up of multiple groups, each with their own categories and areas of responsibility.
We plan in monthly cycles in accordance with our Product Development Timeline. While meeting this timeline is up to the discretion of individual groups, a typical planning cycle is suggested to look like:
estimation::neededlabel applied to make estimation easier and be marked for the coming release as
Deliverable. Issues of particular significance to our stage's strategy should be marked with
Before work can begin on an issue, we should estimate it first after a preliminary investigation.
Separate issues should be created for each discipline that's involved (see an example), and scheduled issues without a weight should be assigned the "estimation:needed" label.
When estimating development work, please assign an issue an appropriate weight:
|1||The simplest possible change. We are confident there will be no side effects.|
|2||A simple change (minimal code changes), where we understand all of the requirements.|
|3||A simple change, but the code footprint is bigger (e.g. lots of different files, or tests effected). The requirements are clear.|
|5||A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way.|
|8||A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements.|
|13||A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. 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.|
For UX issues, please use a similar methodology:
|1||Mostly small to medium UI changes, smaller UX improvements, without unanswered questions|
|2||Simple UI or UX change where we understand all of the requirements, but may need to find solutions to known questions/problems.|
|3||A simple 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.|
|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.|
|8||A complex change 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.|
|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.|
As part of estimation, if you feel the issue is in an appropriate state for an engineer to start working on it, please add the ~"workflow::ready for development" label. Alternatively, if there are still requirements to be defined or questions to be answered that you feel an engineer won't be able to easily resolve, please add the ~"workflow::blocked" label. Issues with the
workflow::blocked label will appear in their own column on our planning board, making it clear that they need further attention.
Once an issue has been estimated, the
estimation:needed label can be replaced with
Our priorities should follow overall guidance for Product. This should be reflected in the priority label for scheduled issues:
|Priority||Description||Probability of shipping in milestone|
|P1||Urgent: top priority for achieving in the given milestone. These issues are the most important goals for a release and should be worked on first; some may be time-critical or unblock dependencies.||~100%|
|P2||High: important issues that have significant positive impact to the business or technical debt. Important, but not time-critical or blocking others.||~75%|
|P3||Normal: incremental improvements to existing features. These are important iterations, but deemed non-critical.||~50%|
|P4||Low: stretch issues that are acceptable to postpone into a future release.||~25%|
Generally speaking, issues are in one of two states:
Basecamp thinks about these stages in relation to the climb and descent of a hill.
While individual groups are free to use as many stages in the Product Development Flow workflow as they find useful, we should be somewhat prescriptive on how issues transition from "figuring it out" to "build it".
After the Kickoff, the Manage stage conducts an asynchronous retrospective on the prior release. You can find current and past retrospectives for Manage in https://gitlab.com/gl-retrospectives/manage/issues/.
Everyone at GitLab has the freedom to manage their work as they see fit, because we measure results, not hours. Part of this is the opportunity to work on items that aren't scheduled as part of the regular monthly release. This is mostly a reiteration of items elsewhere in the handbook, and it is here to make those explicit:
When you pick something to work on, please:
#s_manageto encourage transparency
While group Import follows the Manage's process described above, we utilize additional flows that help us better prepare issues for scheduling into milestones.
In order to assign an incoming issue to a milestone or close it, the product manager may require input from the engineers.
To facilitate an asynchronous triage question and answer flow, the issue is labeled with the
triage question label and the team members are invited into a thread where the question is discussed. Any team member can answer the question and mention the product manager in the answer. If the product manager has enough information to triage the issue, the
triage question label is removed and the issue is assigned to the appropriate milestone or closed as infeasible.
For an issue to be deemed
workflow::ready for development, the issue goes through a refinement stage, where the engineers, the product manager, and other stable counterparts are able to evaluate the issue, ask any clarifying questions, and discuss potential approaches. At the end of that conversation, the issue can be deemed
workflow::ready for development, marked for further breakdown or even canceled if determined not feasible. As the team creates context around the issue, they also estimate the weight during this phase.
All issues considered for the next 1-3 milestones need to go through the refinement, in order to be ready for scheduling into a specific release. Refining issues that are being considered for releases further in the future than the next 3 milestones is not recommended, as it may lead to throw-away effort.
To place an issue into refinement, the issue is labeled with
workflow::refinement. A comment thread is created in the issue to invite the team members to evaluate the issue asynchronously and vote (using emojis) whether the issue is ready for development or not. Any "no" votes are explained and further discussed in comments until the vote becomes a "yes", or the issue is removed from consideration.
Emojis are also used to vote for the issue weight. Any outlier votes are discussed in comments until a compromise is reached. Large estimates are also discussed to determine if the issue can be broken down further.
If the issue has all "yes" votes and has a weight estimate, it is deemed
workflow::ready for development.
Prior to the planning meeting, a milestone priority is assigned to each issue. To avoid collisions of the milestone priorities with the P1-P4 bug and security priorities, we use the
milestone::p4 labels. This process is experimental and will be finalized once we are able to evaluate and discuss the usefulness of these labels.
Although we have a bias for asynchronous communication, synchronous meetings are necessary and should adhere to our communication guidelines. Some regular meetings that take place in Manage are:
|Weekly||Group-level meeting||Backend Engineering Managers||Ensure current release is on track by walking the board, unblock specific issues|
|Every 2 weeks||Stage-level Product/UX||@jeremy||Collaborate on WIP design, brainstorm together on specific problems|
|Every 2 weeks||Stage-level Product/Engineering||@jeremy||Collaborate across groups on specific issues, discuss global stage-level optimization (process, people)|
|Monthly||Stage-level meeting (Manage Monthly)||@jeremy||Stage-level news, objectives, accomplishments|
|Monthly||Stage-level social call||@dennis||Getting to know each other|
|Monthly||Planning meetings||Product Managers||See Planning section|
For one-off, topic specific meetings, please always consider recording these calls and sharing them (or taking notes in a publicly available document).
Meetings that are not 1:1s or covering confidential topics should be added to the Manage Shared calendar.
All meetings should have an agenda prepared at least 12 hours in advance. If this is not the case, you are not obligated to attend the meeting. Consider meetings canceled if they do not have an agenda by the start time of the meeting.
The following people are permanent members of the Manage stage:
|Drew Blessing||Backend Engineer, Manage:Access|
|Dennis Tang||Frontend Engineering Manager, Manage:Access & Manage:Compliance & Manage:Import|
|Martin Wortschack||Frontend Engineering Manager, Manage:Analytics (Interim)|
|Brandon Labuschagne||Frontend Engineer, Manage:Analytics|
|Michael L.||Senior Frontend Engineer, Manage:Analytics|
|Ezekiel Kigbo||Frontend Engineer, Manage:Analytics|
|Illya Klymov||Senior Frontend Engineer, Manage:Import|
|Jiaan Louw||Frontend Engineer, Manage:Compliance|
|Robert Hunt||Frontend Engineer, Manage:Compliance|
|Peter Hegman||Frontend Engineer, Manage:Access|
|Liam McAndrew||Backend Engineering Manager, Manage:Access|
|James Edwards-Jones||Backend Engineer, Manage:Access|
|Luca Williams||Product Manager, Manage|
|Jeremy Watson||Group Manager, Product Management, Manage|
|Matt Gonzales||Senior Product Manager, Manage:Compliance|
|Haris Delalić||Senior Product Manager, Manage:Import|
|Melissa Ushakov||Senior Product Manager, Manage:Access|
|Alex Pooley||Senior Backend Engineer, Manage:Access|
|Imre Farkas||Senior Backend Engineer, Manage:Access|
|Manoj M J||Backend Engineer, Manage:Access|
|Adam Hegyi||Senior Backend Engineer, Manage:Analytics|
|Sebastián Arcila-Valenzuela||Senior Backend Engineer, Manage:Access|
|George Koltsov||Backend Engineer, Manage:Import|
|Josianne Hyson||Backend Engineer, Manage:Import|
|Magdalena Frankiewicz||Backend Engineer, Manage:Analytics|
|Sanad Liaquat||Senior Software Engineer in Test, Manage:Access|
|John-Mason Shackelford||Principal Product Manager, Manage:Analytics|
|Małgorzata Ksionek||Senior Backend Engineer, Manage:Access|
|Pavel Shutsin||Senior Backend Engineer, Manage:Analytics|
|Nick Post||Senior Product Designer, Manage:Analytics|
|Daniel Mora||Senior Product Designer, Manage:Access|
|Amanda Hughes||Senior Product Designer, Manage:Import|
|A.R.||Senior Product Designer, Manage:Compliance|
|Aishwarya Subramanian||Backend Engineer, Manage:Compliance|
|Dan Jensen||Backend Engineering Manager, Manage, Manage:Analytics & Manage:Compliance|
|Mike Jang||Senior Technical Writer, Manage (Access, Compliance, Import, Analytics)|
|Kassio Borges||Senior Backend Engineer, Manage:Import|
|Tan Le||Backend Engineer, Manage:Compliance|
|Max Woolf||Senior Backend Engineer, Manage:Compliance|
|Andrzej Wieckowski||Senior UX Researcher, Manage and Plan|