@@ -125,6 +125,73 @@ Not owned by Security Capabilities Engineering:
3.**Stakeholder Communication**: Tailored reporting for different audiences
4.**Continuous Improvement**: Feedback loops to refine processes and priorities
### Work Tracking
Data is important to our team. We need data to make sure we are:
- Planning and prioritising the [right type of work](#right-type-of-work)(to make progress on our mission, and help achieve Operating Model goals)
- Making room and picking up work mid-milestone to meet our BAU/KTLO responsibilities and accommodate important, last-minute requests (i.e. unplanned work)
- Scoping and sizing our work accurately (so we can effectively set quarterly and strategic goals)
- Raising risks, dependencies, and blockers early (so we can proactively manage them)
- Providing stakeholders visibility into our progress
In order to make sure we can measure this across all three teams consistently, Security Capabilities Engineering has adopted the following work tracking practices:
| Tracking Dimension | Scale/Labels | What We Measure | Why |
| Planning Periods | [Product Milestones](/handbook/product/product-processes/milestones/) | How often we plan work | We plan using Product Milestones to align our work with our stakeholders in Product and Engineering |
| **Priority** | `priority::1` (Urgent)<br>`priority::2` (High)<br>`priority::3` (Medium)<br>`priority::4` (Low) | Urgency and importance of work;<br>Target resolution timeframes | Ensures we address critical security work first, set stakeholder expectations, and align on milestones and due dates across teams |
| **Work Planning** | `Unplanned` label | Work added after milestone planning;<br>Planned vs unplanned capacity ratio | Helps us balance proactive work with reactive BAU/KTLO responsibilities and identify sources of interruptions to minimize future disruption |
| **Sizing & Effort** | Weight: 1, 2, 3, 5, 8<br>(Fibonacci sequence) | Complexity and effort required;<br>Team capacity and velocity | Enables accurate milestone and quarterly planning, assists in tracking % of planned/unplanned work, and helps identify when work needs to be broken down into manageable pieces |
Details of these practices are captured below.
#### Right Type of Work
Work for our teams comes from multiple different sources, which varies by team. In general, when striking a balance on the "right" type of work, we always consider:
- If work aligns with company goals
- If work aligns with strategic capabilities development
- If work aligns with building and giving feedback on GitLab product capabilities
- If work is aligned with strategic goals and critical projects
- If work is BAU and/or time sensitive to meet our responsibilities and commitments to customers and GitLab
#### Priority
We use the standard [GitLab Engineering priority scoped labels](/handbook/product-development/how-we-work/issue-triage/#priority) to reflect the priority of individual issues. Specific use cases are:
| Priority | Importance | Intention | Use Case |
| -------- | ---------- | --------- | --- |
| `~"priority::1"` | Urgent | We will address this as soon as possible regardless of the limit on our team capacity. Our target resolution time is 30 days. | Security incidents, active exploits, P1 vulnerabilities, production blockers |
| `~"priority::2"` | High | We will address this soon and will provide capacity from our team for it in the next few releases. This will likely get resolved in 60-90 days. | Important security improvements, P2 vulnerabilities, planned security features |
| `~"priority::3"` | Medium | We want to address this but may have other higher priority items. This will likely get resolved in 90-120 days. | Standard security work, technical debt, P3 vulnerabilities |
| `~"priority::4"` | Low | We don't have visibility when this will be addressed. No timeline designated. | Nice-to-have improvements, documentation, minor enhancements |
Priority is decided during milestone planning by the EM, and is informed by company-wide critical projects, stakeholder requests, customer commitments, risk ratings, and team needs.
#### Unplanned work and interruptions
We use the existing `~Unplanned` label on issues and MR that are added to the milestone after planning has been decided. This is regardless if it is work that can be done at any point during the milestone, or is something the team need to immediately switch to (urgent interruption).
This is important so that we can tell if our planned vs unplanned capacity percentages are appropriate, and we can identify the source or reason behind late work items (so we can minimize or set better expectations in the future).
#### Sizing and estimates
We use the standard [(modified) Fibonacci sequence scale](https://docs.gitlab.com/tutorials/scrum_events/standups_retrospectives_velocity/#deciding-the-value-of-story-points) to set issue weight. This allows us to track effort and resources needed to complete the work, based on the complexity.
| Weight | Complexity | Time Estimate | Use Case |
| --- | --- | --- | --- |
| 1 | Trivial, the simplest possible change; We are confident there will be no side effects | 1 day | Documentation updates, simple config changes or bug fix |
| 2 | Small, needs some testing but nothing involved; We understand all of the requirements | 1-2 days | Small bug fixes, minor feature additions |
| 3 | Moderate, will take some time and collaboration; The code footprint is bigger but the requirements are clear | 2-3 days | Standard security reviews, feature work that impacts a few files/tests |
| 5 | Complex, will take significant time and collaboration to finish; Requirements understood but likely gaps to workthrough along the way | 3-5 days | Security architecture changes, complex integrations |
| 8 | Very Complex, requires a high level of investigation and research before starting work; Involves much of the codebase and requires input from many to understand the requirements | 5-10 days | Major security initiatives, large refactors |
This generally results in about 20 weight of work items per milestone (per team member), and is reduced based on other commitments (i.e. leave, holidays, G&D). A percentage of this would be planned in advanced of the milestone starting (60-80%), and the remaining weight capacity would be allocated during the milestone for unplanned, reactive work.
While milestone capacity is largely driven by time estimates, our team also considers the level of complexity when priorising work too. For example, commiting to multiple complex work items during a milestone carries a high amount of risk as it is possible we uncover gaps or additional work that needs doing and this could increase the time estimate. Our teams focuses on finding a balance of complexity, within a the maximum weight limit, for each milestone.
