Milestone Planning

Milestone Planning

The Product Security Engineering team plans its work on a cadence based around GitLab Product Milestones. This page describes the planning process that we use to determine what work will be completed for each Milestone.

Milestone Planning Issue

For each Milestone, a [Milestone Planning issue](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/?label_name[]=Milestone Planning) is created in the Product Security Engineering team repository. The purpose of this issue is to:

• Identify potential work to perform
• Identify refinement gaps and determine how to address them
• Determine what work we’re committing to for the upcoming Milestone
• Set and communicate priority for the work we’ve decided to take on

This issue is the single source of truth for all planning related discussions and decisions related to the upcoming Milestone.

Milestone Planning Process

1. An issue will be created using the Milestone Planning issue template
   1. The issue will be created immediately after planning is finished for the current Milestone
   2. Throughout the current Milestone, Product Security Engineering team members can add work to the upcoming Milestone’s Parking Lot
2. The Product Security Engineering manager will be responsible for completing the checklist items in the Planning Checklist section of the Milestone Planning issue
3. Product Security Engineering team members will add any work being carried over from the previous Milestone into the Milestone Work table
4. The Product Security Engineering team will add potential work items to the Parking Lot section, with a brief explanation of why it would be good to include in the Milestone
   1. Team members can add discussion threads to discuss potential work to pull into the Milestone
   2. Both individual team members and the Product Security Engineering manager can add items to this list
5. The Product Security Engineering team will work together to add new items to the Milestone Work table
   1. Each item being added must be refined before it can be formally committed to
   2. The team member likely to take on the work should review and agree with the Weight, if it wasn’t them who refined the issue.
   3. Once we have refined and committed to the work, the relevant issue needs to be updated with the Milestone, Assignee(s), and Metrics label
6. The Milestone Planning issue should be finalized at least 3 days before the Milestone Start Date
   1. The Product Security Manager will use threads in the Milestone Planning issue to work with each Product Security Engineering team member to finalize their workload
   2. Once finalized, the Planning Issue should be closed and an issue for the next Milestone should be opened

Milestone Planning Responsibilities

Product Security Engineering team members are responsible for:

• Evaluating and communicating their capacity for the Milestone (based on PTO and other factors)
• Adding work that is being carried over into the Milestone Work table
• Adding potential work items to the Parking Lot and being involved in discussions around what work we should pull into the Milestone
• Collaborating with the Product Security Engineering manager to finalize the set of work being committed to for the Milestone

The Product Security Engineering manager is responsible for:

• Creating, updating, and maintaining the Milestone Planning issue
• Collaborating with Product Security Engineering team members to discuss potential work, identify refinement gaps, and assemble the Milestone Work table
• Coordinating the finalization of the Milestone Planning issue

Retrospectives

After each Milestone, the Product Security Engineering team participates in an asynchronous retrospective. The purpose of this retrospective is to recognize things that went well, recognize things that didn’t go well, and to identify changes that we should implement.

Retrospectives are captured in sub-tasks to the relevant Milestone Planning issues. Team members may choose to add items to the retrospective over the course of the Milestone, but should also feel empowered to concentrate on the Milestone work itself and think about retro items later.

By default, these retrospectives should have a due date of 2 weeks after the Milestone end date. However, team members can always add items to the retrospective after the due date.

View page source - Edit this page - please contribute.