Commit c1e82edb authored by Dennis van Rooijen's avatar Dennis van Rooijen
Browse files

Data Team planning

parent 29cd4ef2
Loading
Loading
Loading
Loading
+36 −58
Original line number Diff line number Diff line
---
title: "Data Team - Planning Process"
description: "GitLab Data Team OKR and Iteration planning process"
description: "GitLab Data Team Level-3 Epic and Iteration planning process"
---

## Data Team Planning Process

The Data Team Planning Process is a pre-set activity that happens every quarter. The Planning Process adheres to GitLab's financial year/quarter schedule and [Quarterly Objective and Key Results](/handbook/company/okrs/) for prioritization and alignment. The goal of the Planning Process is to improve our ability to prioritize, plan and estimate work through collaboration and transparency.
The Data Team Planning Process is a pre-set activity that happens every quarter. The Planning Process adheres to [GitLab's operating model](https://internal.gitlab.com/handbook/company/gitlab-operating-model/) for prioritization and alignment. This page describes the specifics and details applicable to the Data Team planning process. 

This approach has many benefits, including:
## Quarterly Planning

1. It helps ensure the highest priority projects are being completed
1. It can help leadership identify issues that are blocked
1. It provides visibility into the work of the data team, including specialty analysts whose priorities are set from outside the data function
1. It encourages consistent throughput from team members
1. It makes clear to stakeholders where their ask is in priority
1. It makes clear to all team where their duty is in priority
1. It helps alleviate the pressure of planning the next iteration, as issues are already ranked
Data Team [Level-3 Epics](https://internal.gitlab.com/handbook/company/gitlab-operating-model/gitlab-operating-model-epics/) will align with divisional and company initiatives. For foundational improvements/infrastructure development, the Data Team will also create Level-3 Epics even if these Level-3 Epics are not easy to map. Overall, Level-3 Epics constitute 50-60% of the Data Team's Quarterly Capacity, with Production Maintenance as the only established higher priority. Business Operations work will planned during iteration planning based on available capacity.

## Quarterly OKR Planning
Currently we use a [gSheet](https://docs.google.com/spreadsheets/d/1GdxyiAsgRiIFGN9w6z0pndL0GCZNwSJULHxstz1k72U/edit?usp=sharing) predominantly for team member capacity calculation. Data Team Level-3 Epics are **managed** with [GitLab Epics](https://gitlab.com/groups/gitlab-operating-model/-/work_items).

Data Team OKRs aspire to align with divisional and company OKRs as well as GitLab Yearlies. The Data Team will also create OKRs for [Data Platform](/handbook/enterprise-data/platform/) infrastructure development and these OKRs may not always map to immediate term Business Partner OKRs. Overall, OKRs constitute 50-60% of the Data Team's Quarterly Capacity, with Production Operations as the only established higher priority.
### Planning Level-3 Epics

Currently we do our planning via a [gSheet](https://docs.google.com/spreadsheets/d/16-KbbdgO3rWt-jrvQsgfJagPIfv5asULXaGdnzBbfk8/edit?usp=sharing) which gets communicated with all team members and stakeholders. Data Team OKRs are **managed** with [GitLab Plan](https://about.gitlab.com/direction/plan/) using a combination of Objectives, Key Results, Epics, and Issues.

This approach:

- enables async contributions and planning
- clearly defines Data Team priorities
- leverages KR health statuses for progress reporting

OKRs across the Data Team are written using GitLab's [How to Write OKRs](/handbook/company/okrs/okrs-basics/#how-to-write-okrs) handbook page. The below formulas are used to write OKRs:

- Objectives: Verb + What you want to do + In order to/for/so that (what you hope to achieve or rationale for objective). Objective Example: Increase awareness of company in the market in order to increase sales.
- Key Results: Verb + what you're going to measure + from "x to y". Key Result Example: 100% of employees certified on OKR expectations and process.

### Planning OKRs

OKRs are drafted in collaboration with our Business Partners and every KRs that is put up for scheduling must have an opportunity canvas, see the [project intake](/handbook/enterprise-data/how-we-work/#project-intake). Everyone at GitLab is welcome to [open](https://gitlab.com/gitlab-data/analytics/-/blob/master/.gitlab/issue_templates/%5BNew%20Request%5D%20Create%20Opportunity%20Canvas.md?ref_type=heads) an opportunity canvas and we ask the Data Team members to contribute to the planning process by updating the gSheet with KRs they think are important and should be considered for scheduling. This collaborative approach ensures that all team members have a voice in the planning process and can contribute their insights and expertise.

Once the initial draft of OKRs is complete, the Data Leadership Team reviews and refines the OKRs to ensure alignment with company goals and strategic priorities. The finalized OKRs are then communicated to the entire Data Team and relevant stakeholders. If needed prioritization is raised and discussed within the Data Leadership Forum. KRs are converted into GitLabs [OKR functionality](https://docs.gitlab.com/ee/user/okrs.html).
Level-3 Epics are drafted in collaboration with our Business Partners and every Level-3 Epic that is put up for scheduling must have an opportunity canvas, see the [project intake](/handbook/enterprise-data/how-we-work/#project-intake). Everyone at GitLab is welcome to [open](https://gitlab.com/gitlab-data/analytics/-/blob/master/.gitlab/issue_templates/%5BNew%20Request%5D%20Create%20Opportunity%20Canvas.md?ref_type=heads) an opportunity canvas and we ask the Data Team members to contribute to the planning process by updating the gSheet with their initiatives if they think they are important and should be considered for scheduling. This collaborative approach ensures that all team members have a voice in the planning process and can contribute their insights and expertise.

### Prioritization

@@ -53,7 +30,7 @@ We use a scoring system to evaluate each of these factors, which helps us calcul

priority_score = `(Strategic Alignment + Time Criticality + Revenue or Efficiency Impact + Regulatory or Legal Impact) / Job Size`

Note: Carry-over KRs are prioritized (if still applicable) as we want to complete ongoing work first to achieve results.
Note: Carry-over Level-3 Epics are prioritized (if still applicable) as we want to complete ongoing work first to achieve results.

#### Scoring breakdown

@@ -70,7 +47,7 @@ Value drivers:
| ------------ | -- | - | - | - | -- | --- |
| T-Shirt Size | XS | S | M | L | XL | XXL |

As the Job size is an important factor, we encourage to breakup KRs (over multiple quarters) which aligns with GitLabs value of [iteration](/handbook/values/#iteration).
As the Job size is an important factor, we encourage breaking up Level-3 Epics (over multiple quarters) which aligns with GitLab's value of [iteration](/handbook/values/#iteration) with a clear definition of done that defines the scope for that quarter.

#### T-Shirt Sizing Approach

@@ -85,68 +62,69 @@ We use a T-Shirt sizing approach for quickly sizing the work required to deliver
| XL | 1-2 Months | 26 | New Data Pump to new system. New Data Source with complex source API. |
| XXL | 2-4 Months | 52+ | New Dimensional Model subject area with New Data Sources. |

#### Assigning KRs
#### Assigning Level-3 Epics

We encourage all Data Team Members to add their name to a KR in the list for the upcoming quarter (`Column F` - `Data Team DRI`) if they prefer to get a particular KR assigned to them. Possible reasons (not limited) to indicate you are up for a specific KR is that this is inline with your experience and expertise, previously worked on that area or the aspiration to learn more about it. You can also discuss with your manager the KRs you are interested in contributing to when you add your name as a Data Team DRI. It is not a guarantee it will also be assigned as this depends on other factors as well.
We encourage all Data Team Members to add their name to an initiative in the sheet for the upcoming quarter (`Column F` - `Data Team DRI`) if they prefer to get a particular Level-3 Epic assigned to them. Possible reasons (not limited) to indicate you are interested in a specific Level-3 Epic include alignment with your experience and expertise, previous work in that area, or the aspiration to learn more about it. You can also discuss with your manager the Level-3 Epics you are interested in contributing to when you add your name as a Data Team DRI. It is not a guarantee it will be assigned, as this depends on other factors as well.

Assigning KRs will happen towards the end of the quarter by adding team members and issue points `Columns Q - X` to the KRs.
Assigning Level-3 Epics will happen towards the end of the quarter by adding team members and issue points `Columns Q - X` to the Level-3 Epics.

### Data Platform Vision and KRs
### Data Platform Vision and Level-3 Epics

Although we encourage everyone within the team to contribute, in particular [Staff](/job-families/marketing/enterprise-data/data-engineer/#staff-data-engineer)+ level Data Engineers are expected to contribute to the long-term vision and strategic [direction](/handbook/enterprise-data/organization/engineering/) of the Data Platform, ensuring that our infrastructure and capabilities evolve to meet the changing needs of the business. They do this by discussing quarterly our Data Platform vision and translate if needed into KRs. Any updates or outcomes from these discussions are incorporated into the overall OKR planning process and communicated to the entire Data Team.
Although we encourage everyone within the team to contribute, Staff+ [level](/handbook/enterprise-data/organization/#data-roles-and-career-development) Data Team Members in particular are expected to contribute to the long-term vision and strategic direction of the Data Program. This means ensuring that we meet the evolving needs of our Business Partners by translating these into initiatives and opportunity canvases.

Key aspects include:

1. Translate company objectives into Data Products
1. Understanding our Business Partners' challenges
1. Identifying emerging technologies and trends in data engineering
1. Assessing current platform limitations and areas for improvement
1. Aligning platform development with overall company strategy
1. Proposing innovative solutions to enhance data processing, storage, and analysis capabilities
1. Collaborating with other teams to understand their evolving data needs

The resulting KRs from these discussions are integrated into the quarterly OKR planning process, ensuring that the Data Platform's development is aligned with both immediate business needs and long-term strategic goals.
The resulting initiatives from these discussions are integrated into the quarterly planning process, ensuring that the Data Platform's development is aligned with both immediate business needs and long-term strategic goals.

### OKR Tracking and Reporting
### Level-3 Epic Tracking and Reporting

We use GitLab's built-in OKR tracking features to monitor progress throughout the quarter. Each Key Result is updated regularly, at least once per month, and the overall health status of Objectives is assessed based on the progress of their associated Key Results.
We use GitLab Epics to monitor progress throughout the quarter. Each Level-3 Epic's progress is updated weekly in the Epic. The designated Data Team Sponsor is responsible for providing a written update in the epic, including health status and actual metrics.

Progress on OKRs is reported in the following ways:
#### Level-4 Epics

1. Weekly Data Team meetings: A brief update on key OKRs is provided.
2. Monthly in GitLabs OKR feature: A more detailed review of OKR progress, including any blockers or risks.
In FY27Q1 planning cycle we learned that we had Level-3 Epics defined at too granular a level. In FY27Q2 we will introduce Level-4 Epics. The following structure will apply, where in FY27Q1 the Level-4 Epic level is skipped.

#### OKR Structure
##### Level-3 Epic Structure

```mermaid
graph TD
    Planning-gSheet[Planning Gsheet]
    Planning-iteration(((Planning iterations)))
    Objective[Objective]
    KeyResult1[KeyResult-1]
    KeyResultN[KeyResult-N]
    Level2Epic[Level-2 Epic - CIO]
    Level2Epic-->Level3Epic
    Level3Epic[Level-3 Epic]
    Level4Epic1[Level-4 Epic-1]
    Level4EpicN[Level-4 Epic-N]
    Epic[Epic]
    Issues1[Issues-1]
    IssuesN[Issue-N]
    Planning-gSheet-.->Planning-iteration-.->Planning-gSheet
    Planning-gSheet-->Objective
    Objective-->KeyResult1
    Objective-->KeyResultN
    KeyResult1-->Epic
    Planning-gSheet-->Level3Epic
    Level3Epic-->Level4Epic1
    Level3Epic-->Level4EpicN
    Level4Epic1-->Epic
    Epic-->Issues1
    Epic-->IssuesN
```

## Work Breakdowns

Work breakdowns are always developed as a part of the Quarterly OKR Planning Process, but can also be leveraged to help scope and plan new initiatives, infrastructure projects, and similar multi-person or multi-week projects. The outcome of the work breakdown is a detailed description of the work to be performed, deliverables and responsibilities, and a high-level timeline.
Work breakdowns are always developed as a result of the Quarterly Planning Process, but can also be leveraged to help scope and plan new initiatives, infrastructure projects, and similar multi-person or multi-week projects. The outcome of the work breakdown is a detailed description of the work to be performed, deliverables, responsibilities, and a high-level timeline.

- As a part of the Quarterly OKR Planning Process, work breakdowns are embedded in the KR Description.
- As a part of a stand-alone or ad-hoc initiative, work breakdowns are embedded in the appropriate Epic Description.
- As an example of a Work Breakdown, see this [FY22-Q4 Data Platform Work Breakdown](https://gitlab.com/groups/gitlab-data/-/epics/372).
As a part of the Quarterly Planning Process, work breakdowns are linked to the Level-3 Epic Description.

Work Breakdowns consider the following inputs:

1. Defined upcoming OKRs
2. OKR Reviews
1. Defined upcoming Level-3 Epics
2. Level-3 Epic Reviews
3. New / forward looking insights
4. Team availability
5. Team member ambitions
@@ -175,6 +153,6 @@ The timeline for Iteration planning is as follows:
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0 - 1st Wednesday | **Iteration Start** <br><br>                      | -                                                                                                                                                                                                                        |
| 7 - 1st Tuesday   | **Midpoint** <br><br>Any issues that are at risk of slipping from the iteration must be raised by the assignee                                               | -                                                                                                                                                                                                                        |
| 10 - 2nd Friday   | **The last day to submit MRs for review** <br><br>MRs must include documentation and testing to be ready to merge <br><br>MRs are preferably not to be merged on Fridays, or on Thursday in the case of Family and Friends Day, (unless there is urgency, i.e. P1-Ops related MRs or in cases with tight timelines) to minimise impact on days where there is limited team member availability. | **Iteration is roughly final** <br><br>Iteration Planner verifies issue priority and team capacity for next iteration.                                                                                                     |
| 10 - 2nd Friday   | **The last day to submit MRs for review** <br><br>MRs must include documentation and testing to be ready to merge <br><br>MRs are preferably not to be merged on Fridays (unless there is urgency, i.e. P1-Ops related MRs or in cases with tight timelines) to minimise impact on days where there is limited team member availability. | **Iteration is roughly final** <br><br>Iteration Planner verifies issue priority and team capacity for next iteration.                                                                                                     |
| 13 - 2nd Monday   | **Last day of Iteration** <br><br>Ready MRs can be merged                                                                                                    | -                                                                                                                                                                                                                        |
| 14 - 2nd Tuesday  | **Meeting Day** <br><br> All unfinished issues either need to be removed from iterations or rolled to the next                                               | **Iteration Planning** <br><br> Sync-meeting to perform retro perspective on the current iteration and align/start on the next iteration according to the created iteration planning. All unfinished issues either need to be removed from iterations or will be automatically rolled to the next |
+4 −4
Original line number Diff line number Diff line
@@ -90,7 +90,7 @@ See [Data Team Internships](/handbook/enterprise-data/organization/internships/)
| By Day 30 | By Day 60 |  By Day 90 | By Day 120 |
| ------ | ------ |------ |------ |
| Complete People and Data Onboarding | Perform [triage](/handbook/enterprise-data/how-we-work/triage/) activities | Extract [new data sources](/handbook/enterprise-data/how-we-work/new-data-source/) | Own a specific area of the data platform |
| Create a MR to contribute to handbook or templates | Investigate incidents and issues | Work on [OKR assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-okr-planning) | Propose new ideas and come up with Data Platform improvement initiatives |
| Create a MR to contribute to handbook or templates | Investigate incidents and issues | Work on [Level-3 Epic assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-planning) | Propose new ideas and come up with Data Platform improvement initiatives |
| Understand the current setup of the data platform | Make small/corrective changes to the platform infrastructure or data pipelines | Contribute on work breakdown | |

### Data Analyst
@@ -141,7 +141,7 @@ See [Data Team Internships](/handbook/enterprise-data/organization/internships/)
| By Day 30 | By Day 60 |  By Day 90 | By Day 120 |
| ------ | ------ |------ |------ |
| Complete People and Data Onboarding | Meet stakeholders across the organization | Re-train or enhance an existing data science model |  Make a contribution to improve the Data Science handbook, packages, or processes |
| Start attending Data Science Team meetings | Refine/improve one data science dashboard | Work on [OKR assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-okr-planning) | Take ownership of at least one quarterly OKR |
| Start attending Data Science Team meetings | Refine/improve one data science dashboard | Work on [Level-3 Epic assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-planning) | Take ownership of at least one quarterly OKR |
| Understand the current data science systems and processes |  | |  |

### Analytics Engineering
@@ -197,7 +197,7 @@ See [Data Team Internships](/handbook/enterprise-data/organization/internships/)
| By Day 30 | By Day 60 |  By Day 90 | By Day 120 |
| ------ | ------ |------ |------ |
| Complete People and Data Onboarding | Take up tasks related to assigned program | Own epic / KR from planning to execution | Own specific data domain for data governance and data quality improvement |
| Fully understand the data governance and data quality program, priorities and its strategy | Investigate incidents and issues | Work on [OKR assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-okr-planning) | Collaborate cross functionally and identify areas for improvement |
| Fully understand the data governance and data quality program, priorities and its strategy | Investigate incidents and issues | Work on [Level-3 Epic assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-planning) | Collaborate cross functionally and identify areas for improvement |
| Create a MR to contribute to handbook or templates |  |  |  |

### Data Governance and Quality Program Manager Job Family
@@ -239,7 +239,7 @@ See [Data Team Internships](/handbook/enterprise-data/organization/internships/)
| By Day 30 | By Day 60 |  By Day 90 | By Day 120 |
| ------ | ------ |------ |------ |
| Complete People, Data, and Manager Onboarding | Meet everyone on the team and business data champions | Complete a Team Assessment | Draft a people development Roadmap |
| Understand the current setup of the data platform | Work on [OKR assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-okr-planning) and map them to the data platform | Lead discussions with Users/Stakeholders on initiatives and OKRs | Draft a program development Roadmap (Process Improvements /Future State) |
| Understand the current setup of the data platform | Work on [Level-3 Epic assignments](/handbook/enterprise-data/how-we-work/planning/#quarterly-planning) and map them to the data platform | Lead discussions with Users/Stakeholders on initiatives and OKRs | Draft a program development Roadmap (Process Improvements /Future State) |
| Add a new page to the handbook | Make regular contributions to the handbook spanning your area of management | Become DRI for major portions of the Data Handbook | System/Application Change Control Management of one or more modules |

## Tool Technology Tandem