gitlab-project-management

# GitLab for Project Managers

---
# Help us understand your background

## GitLab experience?
beginner, intermediate, advanced 
 
 
## Project management experience?
beginner, intermediate, advanced

---
# Learning Objectives
- Explain what the GitLab Plan Stage covers in the SDLC
- Plan work with groups, projects, epics, and issues
- Track progress with issue boards, roadmaps, milestones, and iterations
- Use GitLab with Kanban, Scrum, and Waterfall workflows

## Practice all concepts with a start-to-finish use case

---
# Course Agenda

## Part 1
Module 1: Intro to the Plan stage 
Module 2: Intro the project organization in GitLab 
Module 3: Using GitLab to plan and start projects 
Module 4: Intro to issues

## Part 2
**Module 5**: Deep dive into issues 
**Module 6**: Code reviews and approvals 
**Module 7**: Issue boards 
**Module 8**: Workflow best practices

Notes:
- All times are approximate
- Call for a 5-min break at any time
- Lunch (for 1-day classes) will probably be between part 1 and part 2, but we can be flexible depending on time zones
- Demos throughout the modules (usually demo each concept immediatley after explaining it)
- Labs at end of each module
- Labs repeat the demos (i.e., when instructor demos, they’re previewing the lab for you)

---
<div class="gl-flush-left">

# Getting the most out of training

**Please interrupt with questions or comments**
- Use microphone or chat
- Video optional
- We can slow down or repeat info for non-native English speakers

**Please interrupt with questions or comments**
- Use microphone or chat
- Video optional
- We can slow down or repeat for non-native English speakers

**OK to forget most of the details**
- Show you what's possible
- Give you confidence to re-learn as needed

**Expect circular explanations and repetition**

</div>

Notes:

n/a

---
# GitLab for Project Managers
## [Hands-on Lab Guide](https://about.gitlab.com/handbook/customer-success/professional-services-engineering/education-services/gitlabpmhandson.html)

[https://www.gitlabdemo.com/invite](https://www.gitlabdemo.com/invite)

Notes:
- All labs are done in a training environment. 
- This URL will get you an account in the training environment: https://www.gitlabdemo.com/invite
- Paste https://www.gitlabdemo.com/invite in chat
- Paste class invitation code in chat
Paste Lab Guide in chat: https://pm-course-revamp-demolabs.about.gitlab-review.app/handbook/customer-success/professional-services-engineering/education-services/gitlabpmhandson.html
- Do labs in training sandbox - private group within GitLab
- Do certification in the same environment
- Environment expires after 7 days. We can unlock it after that if you need more time. Email us.
- Questions about what we’ll cover, or course mechanics?

DEMO: Walk through Lab 1 with students

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 1

## Intro to the plan stage
 
At the end of this module, you will be able to:

- Understand how GitLab divides the SDLC into stages
- Explain what GitLab’s plan stage does
- Describe GitLab Flow

---
# GitLab’s 10 stages of the software development lifecycle

Notes:
- Tell students this image is a placeholder only.
- Demonstrate GitLab’s transparency by showing them an up-to-date version: https://about.gitlab.com/direction/maturity/

---
# Focus of this class

We will focus on the plan stage of the software development lifecycle
- Single conversation
- Single data store
- Single permission model
- Single interface
- Governance and security
- Team collaboration
- Lifecycle analytics

Notes:
- We will focus on the Plan stage in the DevOps lifecycle.
- Purpose of Plan Stage: 
 - Plan and organize work
 - Divide work into chunks (issues)
 - Prioritize issues
 - Weight issues
 - Assign issues to devs or other team members
 - Group issues according to themes or deliverables
 - Assign issues to sprints (if you use scrum)
 - Set deadlines for issues, groups or issues, or sprints
 - Track progress of work
 - Who’s doing it?
 - How far have they progressed?
 - Any blockers?
 - Any issues at risk of missing deadline?
- If you use GitLab to plan your work, you can use the same tool that developers use to create, test, secure, and release the software.
- Improves transparency and collaboration.

---
# Focus of this class

Notes:
Alternative view of how the Plan stage fits in to the DevOps/SDLC (we use terms interchangeably)

---
# GitLab workflow for development

Notes:
- This is mostly relevant to developers, but everyone who uses GitLab should be aware of “GitLab Flow”, which is what we call this best-practice workflow.
- This is a **maximalist** example: it uses all the features
- Highlight creating MR at beginning, compared to other systems like GitHub

---
# Question and answer break

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 2

## Intro to project organization in GitLab
 
At the end of this module, you will be able to:

- Describe the role of groups, subgroups, and projects
- Create projects and explain why they are important
- Configure roles and permissions for projects and groups
---
# Create an organizational hierarchy

<table style="border:none;text-align:left;font-size:48px;">
 <tr style="border:none;">
 <td style="border:none;">Group</td>
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 </tr>
 <tr style="border:none;">
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 </tr>
 <tr style="border:none;">
 <td style="border:none;"></td>
 <td style="border:none;">Subgoup</td>
 <td style="border:none;"></td>
 </tr>
 <tr style="border:none;">
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 </tr>
 <tr style="border:none;">
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 <td style="border:none;">Project</td>
 </tr>
</table>

---
# Create an organizational hierarchy

<table style="border:none;text-align:left;">
 <tr style="border:none;font-size:36px;">
 <td style="border:none;"></td>
 <td style="border:none;">Subgroup</td>
 <td style="border:none;">Project</td>
 </tr>
 <tr style="border:none;font-size:48px;">
 <td style="border:none;">Group</td>
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 </tr>
</table>

- Reflects the company’s structure or products:
  - Teams/business units/functional groups
  - Software products or architectures
  - Geographical locations
- Holds certain GitLab components
- Has members
- Grants access permissions to members

Notes:
Group:
- First PM step: “represent” your company’s org structure using groups
- Could use groups to represent anything: 
 - product lines
 - software architectures
 - geographical locations
- Will talk later about what kinds of things a group can hold, but one thing is a **subgroup**

---
# Create an organizational hierarchy

<table style="border:none;text-align:left;">
 <tr style="border:none;font-size:36px;">
 <td style="border:none;">Group</td>
 <td style="border:none;"></td>
 <td style="border:none;">Project</td>
 </tr>
 <tr style="border:none;font-size:48px;">
 <td style="border:none;"></td>
 <td style="border:none;">Subgroup</td>
 <td style="border:none;"></td>
 </tr>
</table>

- Nested group (up to 20 deep)
- Organizes large projects
- More granular control over access permissions
- Reflected in GitLab URLs

---
# Create an organizational hierarchy

<table style="border:none;text-align:left;">
 <tr style="border:none;font-size:36px;">
 <td style="border:none;">Group</td>
 <td style="border:none;">Subgroup</td>
 <td style="border:none;"></td>
 </tr>
 <tr style="border:none;font-size:48px;">
 <td style="border:none;"></td>
 <td style="border:none;"></td>
 <td style="border:none;">Project</td>
 </tr>
</table>

- Lives in a group
- Represents a software project, team, or other entity
- Where teams plan and complete work
- Usually focused on software, but not necessarily!

---
# Groups, subgroups, and projects

<ul ul style="font-size:56px;">
 <li class="fragment">Group:
 <ul style="font-size:48px;">
 <li class="fragment">Subgroup</li>
 <li class="fragment">Project
 <ul style="font-size:36px;">
 <li class="fragment">Issues
 <ul style="font-size:24px;">
 <li class="fragment">Comments</li>
 <li class="fragment">Participants</li>
 <li class="fragment">Assignments</li>
 </ul>
 </li>
 </ul>
 </li>
 </ul>
 </li>
</ul>

Notes:
- Each level can include details from the levels beneath it in its reports.
- Example
 - You’re a VP in charge of “MegaPlus Streaming” subgroup
 - You can see % work done for all projects in your subgroup, all in 1 report
- Don’t be afraid to refactor group hierarchy structure as “hierarchy rot” sets in:
 - organization changes, grows, consolidates
 - initiatives can be introduced, grow, shrink, combine
 - some other group structure just makes more sense
- Groups and subgroups are branches on a tree, projects are the leaves
- We'll discuss issues later
- Summary: Groups, Subgroups, and Projects keep your team and your work organized and separated into logical “areas”

---
# Project: where work happens
- Group
  - Subgroup
    - **Project**

**Projects** are where team members spend most of their time:
- View files in a Git **repository**
- Perform Git operations on files
- Record, discuss, prioritize, assign ideas in **issues**
- Review and approve code in **merge requests**
- View status of **CI/CD pipelines** in a **dashboard**

Notes:
- DEMO: Lab 2 tasks:
 - Review example groups and projects in GitLab
 - Create an organization structure
 - Create a new project

- - -

- Within Groups and/or Sub Groups, are GitLab **Projects**.
- The *Git Repository* is the foundation of a GitLab Project.
  - Having the Repository as the cornerstone upon which GitLab is built is key to providing a single platform for all types of users in an organization.
- An application source code is the basis for delivering value to users and customers
G- iven the hierarchy considered, the tight relationship between the code in the repo and the related Merge Requests, Changes, Reviews, Discussions, Test Results, Logs and Reports, Approvals, and ultimately, functioning, deployed software provides traceability throughout the system.
- A Project can be used for hosting your codebase, be used as an issue tracker, collaborate on code, and continuously build, test, and deploy your app with built-in GitLab CI/CD.
- As part of an organization’s agile portfolio or project management hierarchy, Projects can be used strictly for Issue Tracking, for specific solutions or applications and their related backlogs, or as individual technology projects, part of a larger solution, such as a microservices platform, where visibility across projects is key.

---
# GitLab roles and permissions
## Overview
- **Groups** and **projects** have an **owner** and **member(s)** (who are people)
- **Owners** invite whole **groups** or individual **members**
- **Roles** give **permissions** for that group or project
- Group members **inherit** project roles from their group roles
- Owners **assign** roles to individual members
- See [docs](https://docs.gitlab.com/ee/user/permissions.html) for more info:
  - Full permissions table
  - External users
- “Group” is overloaded
  - Group of projects (or other groups)
  - People who are members of that group

Notes:
- Think you need external users? Consult docs for security-related details
- **Maintainer** and **Owner** are almost the same. 
 - Maintainers can delete some things that owner can’t (e.g., projects and issues).
- Google search “gitlab permissions table” to show the full list of permissions

---
# GitLab roles and permissions

## Maintainer/Owner

- Most permissions
- Normal role for PMs
- Add or delete members
- Establish permissions
- Create items inside groups and projects necessary for Project Management

---
# GitLab roles and permissions

## Developer

- Medium permissions
- Direct contributors
- Read, create, and modify elements of groups and projects

---
# GitLab roles and permissions

## Reporter

- Fewest permissions
- Read-only contributors
- Don’t actively contribute to projects
- View reports and progress

---
# GitLab visibility

## Visibility ≠ roles
- **Roles:** can you **change** things in the project?
- **Visibility:** can you **see** the project page?

## 3 visibility settings
- **Public:** anyone with the URL can view 
- **Internal:** anyone logged in to the GitLab instance can view
- **Private:** only project members can view
- 404 if no visibility

Notes:
- Roles are assigned to people
- Visibility is assigned to projects/groups
- DEMO: Lab 2 task:
 - Set project members, visibility, and permissions

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 2
## Create an organizational structure in GitLab
In this hands-on exercise, you will: 
- Review how Gitlab.com organizes groups and projects
- Create your own subgroups and projects
- Set project members, visibility, and permissions
---
# Question and answer break

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 3

## Using GitLab to plan and start projects
 
At the end of this module, you will be able to:

- Plan work with epics, milestones, and iterations
- Track progress with roadmaps
- Document projects with wikis

---
# Track cross-project features or themes with epics

Notes:
- Epics are another organizational structure, like groups or projects.
- They organize work by theme rather than by project or team:
 - Collect related issues, that share same theme, from 1 or more projects
 - Examples:
 - “Fix documentation” epic that collects Docs fixes from multiple projects
 - “Update the UX” epic that collects Dev, UX, DB tickets from multiple projects
- Epics exist only at **group*** level
- Epics can have **child** epics
- DEMO: Lab 3 tasks:
 - Create an epic and child epic
- - -
- Epics provide for grouping of other Epics and Issues, and enable the management of a portfolio of initiatives, capabilities, or features efficiently
 - Epics exist across Sub Groups sharing a common parent Group, as well as Projects and Milestones
- Issues describe small, discrete pieces of work. An Issue is a User Story, a Bug or Defect, a Non-Functional story, etc.
 - Issues can contain as little or much definition needed to accomplish the work

---
# Group related issues and merge requests in a milestone

- **Milestones** track big goals or deliverables
  - *Release 2.0*
  - *Password management feature is complete*
  - *Presentation at DevOpsDays*

Notes:
- Similar to epics, milestones group issues. But:
 - milestones can also include MRs
 - burndown/burnup charts
- Epics are more for themes, Milestones are more for deliverables.
- DEMO: Lab 3 tasks:
 - Set milestones to represent product goals
- - -
More talking points:
- Milestones in GitLab are a way to track issues and merge requests created to achieve a broader goal in a certain period of time. For example, you might have a lot of issues related to a specific deliverable or goal, you can create a milestone and assign all the issues to it.
- Milestones have a different set of features than labels and issues. Burndown charts and global due dates are the most noticeable.
- If you are Agile, you could use Milestones as a **timebox** (though iterations are now better for this).
- If you are Waterfall, consider using Milestones as **deliverables**.
- Either method, you can still use Milestone **Due Dates!**
- Currently, only *1 milestone per issue*
- Docs:
 - https://docs.gitlab.com/ee/user/project/milestones/

---
# Group related issues and merge requests in a milestone

- Assign **issues** and/or **MRs**
- Same **start date** and **end date** for all tasks
- Exist at **project** or **group** level
- **Burndown** charts
- Each task can belong to 1 milestone and/or 1 epic

---
# Assign a task to a sprint using an iteration

- Iteration ≈ **sprint**
- **Group** level only
- Iterations require **start/end dates**
- Iterations can’t **overlap**

---
# Assign a task to a sprint using an iteration

- Group can have only 1 **active** iteration a time
- Iteration details page
  - % done
  - Burndown & burnup charts

Notes:
- DEMO: Lab 3 tasks:
 - Schedule iterations as team sprints

---
# Epic vs milestone vs iteration

## Epic: single theme
- *Fix documentation typos*
- *Remove performance bottlenecks*
- *Address security vulnerabilities*

## Milestone: single feature or initiative
- *Release 2.1*
- *Bugfixes 1-20 are merged*
- *Foobar2000 integration is complete*

## Iteration: single sprint
- *Sprint 6*

**All 3 are flexible, so experiment!**

Notes:
- If it feels like there’s overlap between these concepts, that’s because there is.
- Different teams use them differently.
- There are some best practices or default ways of using them, but use them however works best for your team.
- 1 common workflow:
 - Assign issues to milestones
 - Assign issues epics
 - Set the milestone due dates
 - Let epics inherit due dates from the milestones that the epic’s issues belong to

---
# Epics inherit due dates from milestones

- An **issue** can be assigned to a **milestone** with a user-specified **due date**
- An **issue** can also assigned to an **epic**

An epic *inherits* due dates from milestones that the epic’s issues belong to

---
# Track progress of epics and milestones with a roadmap

- Similar to a **Gantt chart**
- Timeline that shows **start date** and **end date** for epics and milestones
- Shows progress for **epics**
- Exists at **group** level
- Includes **epics** and **milestones** in the group and subgroups
- Can **sort** and **filter** timelines

Notes:
- DEMO: Lab 3 tasks:
 - Review project planning features in GitLab

---
# Track progress with issue boards (preview)

- Similar to roadmaps, but:
  - Issue boards track **issues**, not epics or milestones
  - Issue boards use **lists** (columns), not timelines

Notes:
- This is just a preview.
- Will say much more about issue boards later, after we’ve introduced issues and labels.

---
# Track progress with issue boards (preview)

- Lists can show issues with certain values:
  - Label
  - Assignee
  - Milestone
  - Iteration
- Used with **Kanban**, **Scrum**, or **Waterfall**
- More info later!

Notes:
- This is just a preview.
- Will say much more about issue boards later, after we’ve introduced issues and labels.

---
# Documenting projects with wikis

- More powerful than a **README**
- Less powerful than **GitLab Pages** (not discussed here)
- **Group** or **project** level
- Many use cases:
  - **Documentation**
  - Scrum **retrospective** notes
  - Team **procedures** or **standards**

Notes:
- For a Wiki to store team procedures or standards (e.g., a writer’s style guide, or a white space guide for programmers):
 - Could make a separate “Standards” project and turn off all features but the Wiki
 - Or group-level Wiki
 - Don’t forget you can add pictures!
 - Example: picture of retrospective whiteboard

---
# More about wikis

- Format text with **Markdown** or other markup languages
- Navigate via **sidebar**
- Stored in a separate **Git repo**:
  - Edit and serve locally
  - Who edited what, when?
  - Revert to earlier versions
- Integrates with **Confluence**

Notes:
- DEMO: Lab 3 tasks:
 - Create a wiki for project documentation

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 3
## Use GitLab project planning tools
In this hands-on exercise, you will: 
- Review how GitLab uses Gitlab’s project planning features
- Create epics, milestones, and iterations
- Store project documentation in a wiki

---
# Question and answer break

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 4

## Intro to issues
 
At the end of this module, you will be able to:

- Describe why issues are the core GitLab project management feature
- Create issues
- Use labels to route and track issues
- Working collaboratively on an issue

---
# Issues

- Describe and track a **single unit of work**
  - Description
  - Metadata (mostly optional)
  - Threaded discussion
- Collaborators
- Exist at **project** level

Notes:
- Issue = task to be accomplished
- Similar to **stories** or **tickets** in other systems or tools.
- We haven’t talked about branches or merge requests yet:
 - Branch, issue, MR are often created at the same time
 - Often have similar names
 - Can be linked in their text fields
- Issues are basic “lego building block” that GitLab and especially GitLab PM is built around

---
# Issues

- Can describe **any work**, not just coding tasks
- Often have a related **branch** and **merge request**
- Atomic building block for Project Management in GitLab
- When in doubt, start with an issue

---
# All work starts with an issue

**When should you create a new issue?**

Notes:
- Can be used for more than coding tasks:
 - Planning events
 - Sharing ideas
 - Asking for info or opinions
 - Filing bugs
 - Managing incidents
- - -
More talking points:
- “Issues” are the basic building blocks of planning development work and are used to collaborate on ideas and planning work in GitLab. 
- You create an issue inside a Project.
- *Q:* When should you create a new issue? 
- *A:* Create a new issue whenever you are developing a new feature to be implemented in one of your applications. Here are some other situations for which you could create an issue:
 - Discuss the implementation of a new idea
 - Manage an incident
 - Ask questions
 - Report bugs
- At GitLab our best practice is to always start a discussion with an issue.
- *Resources*:
 - GitLab Docs: https://docs.gitlab.com/ee/user/project/issues/

---
# Issues link to other GitLab components

Notes:
- Issues can be linked to merge requests and all the other components we’ve talked about so far
- These links allow GitLab to put the whole SDLC within one tool.
- - -
More talking points:
- When you create an issue in GitLab, you can view multiple Devops Lifecycle Stage properties, such as the related epics, merge requests, milestone dates, boards, roadmaps, labels, and more. 
- This slide highlights the “it’s all connected” concept. Single source of truth, that starts with an issue. 
 - https://about.gitlab.com/blog/2016/03/08/gitlab-tutorial-its-all-connected/

---
# Issues: the atomic building blocks of GitLab

- **Projects** contain issues
- **Epics** contain issues
- **Milestones** contain issues
- **Iterations** contain issues
- **Issue** boards display issues
- **Merge requests** are usually linked to issues
- **Groups** inherit issues from their child projects
- **Wikis** can link to issues

Notes:
- Issues are also linked to other things that we won’t discuss in this course, like security scanning reports.

---
# Labels

- Attached to issues, merge requests, epics
 - Assign **ownership**
 - Indicate **status**
 - Set **priority** 
<img src="../gitlab/slides/images/unscoped-labels-example.png" width="533" height="60" alt="Unscoped labels example"/>

- Dynamic **filtering** in different views
- Power **issue boards**
- Non-scoped vs. scoped

Notes:
- Allow filtering on lists of issues, MRs, or epics
- Will learn more about how labels and issue boards interact later when we look at issue boards in more detail
- Scoped labels are mutually exclusive for labels with the same key (left-hand side)
- GitLab provides default labels, or create your own

---
# More about labels

- Subscribe to a label to get notified when it’s added anywhere
- Prioritize labels to sort items by priority
- Use default labels or create your own
  - Exist at project, group, or global level
- Use highest level that makes sense
- **CAUTION:** can apply label with same name from different levels
- 1 item can have multiple labels

Notes:
- Example labels from an actual GitLab MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79244
- If there’s a group-level label called “In Progress” and a project-level label called “In Progress”, you could apply both to the same issue, MR, or epic
- Show list of issues in GitLab’s open source project to see labels in action
- DEMO: Lab 4 tasks:</stron>
 - Create and manage labels

---
# Use cases for filtering with labels

- Show all issues that belong to the UX team     `UX`
- Show all MRs that should be merged ASAP     `ASAP`
- Show all epics that have to do with documentation     `Docs`
- Show all issues that are in Sprint 9     `Sprint::9` 
- Show all MRs that have to do with performance     `Perf`

Notes:
- When describing, concentrate not on the exact label text, but on the reason you might want to use these labels.
- Some of these use cases could be accomplished in other ways. 
 - E.g., instead of sprint::9 label, you could look look at the list of issues in iteration 9.

---
# Collaborating on issues

- **Assign** issue to its owner(s), or use **labels**
- **@mention** collaborators in description or discussion
- Participate in the discussion
  - Threaded responses
  - Markdown with preview
  - Emojis?  👍 💯 😊
  - Images
- Enable **notifications** to get email for any changes

Notes:
- Assignee or issue owner can mean diff things to diff teams
- DEMO: Lab 4 tasks:
 - Create issues for tracking work

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 4
## Create project issues
In this hands-on exercise, you will: 
- Create and manage labels
- Create issues for tracking work
- Apply labels to issues

---
# Question and answer break

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 5

## Deep dive into issues
 
At the end of this module, you will be able to:

- Explain the metadata fields available in issues
- Use quick actions
- Link issues and merge requests
- Perform standard issue-management operations

---
# Issue metadata fields

Notes:
Walk all issue sections, left to right:
- **Left nav bar**
 - Dimmed here b/c it’s not issue-specific; it’s always visible no matter what you’re doing in GitLab
 - Can look different:
 - Changes when you’re in a project vs. a group
 - Changes when you disable features in the project (e.g., turn off Snippets and Wiki)
- **Breadcrumb trail**
 - Quick tool for orienting yourself and navigating
 - Shows all groups and subgroups the project belongs to
 - Shows the project number, which is needed if you want to link it or refer to it elsewhere (e.g., in another project, or in a wiki page)
 - Each entry in breadcrumb trail is a clickable link, for navigation
- **Linked issues:**
 - Relates to
 - Blocks
 - Is blocked by
 - Some dashboards let you filter by these relationships
 - e.g., show me just the blocked issues
- **History**
 - Entry for every change made to the issue
 - Pro-tip: try the **Show comments** only filter option to declutter
- **Discussion**
 - Already discussed in previous module
- **Metadata** pane varies depending on what you’re looking at (issue, MR, milestone, etc.)
 - Some of these fields are settable with quick actions
 - **Assignee**
 - issue “owner”, who is responsible and accountable for driving it forward
 - 0, 1, or multiple people
 - On roadmaps, an issue is considered “in progress” once it has an assignee
 - **Epic, milestone, iteration:**
 - Already discussed
 - Can belong to any or all of these, but only 1 per field (e.g., can belong to 0 or 1 Milestone, 0 or 1 Iteration, etc.)
 - **Time tracking**
 - Time spent or time estimated, or both
 - If both, it shows a “thermometer” showing how much you’ve spent compared to how much you estimated
 - Can only enter via quick action (will discuss quick actions more later, but here’s a preview)
 - `/estimate 1h`
 - `/spend 20h`
 - Spending is cumulative: `/spend 20` and `/spend 10` results in 30 mins spent
 - Can spend negative time to subtract
 - **Due date**
 - Appears wherever you view the issue
 - **Labels**
 - 0, 1 or more
 - Can create or edit labels from here 
 - **Weight**
 - Difficulty or size of issue
 - Like scrum points
 - Typically use Fibonacci numbers, but don’t have to
 - Factors in to reporting about how done an epic, milestone, or iteration is
 - **Health status**
 - Predefined status: On track vs. Needs attention vs. At risk
 - No custom status available
 - Shows up as a label wherever you view the issue
 - **Confidentiality**
 - Limits visibility to people with Reporter role or higher for the project
 - Confidentials means not viewable to the public.
 - Example: security-related bug reports
 - **Lock issue**
 - Only project members can add comments
 - Use with public projects to shut down conversations that get out of control
 - **Participants**: anyone who has taken an action on the issue or is @mentioned.
 - **Notifications**
 - Unlike the other fields, this is a setting just for you
 - When on, you get email whenever changes happen to the project
 - e.g., issue is closed
 - e.g., someone adds a comment
 - Toggled on automatically when you take action or are @mentioned
 - Toggle back off to limit spam

DEMO: Lab 5 tasks:
- Set issue metadata

---
# Common issue operations

- **Link** an issue and an MR with “magic characters”
- **Promote** an issue to an epic
- **Close** an issue
  - Manually
  - Automatically
- **Move** an issue
- **Delete** an issue
- **Bulk** issue edits

Notes:
- Link with **magic characters**
 - `#` for issue
 - ! for MR
 - Get issue number from its breadcrumb trail
 - Show full list: https://docs.gitlab.com/ee/user/project/autocomplete_characters.html
- Promote
 - **kebab icon > Promote to epic**
 - Quick action: `/promote`
- Close
 - Close as soon as the work is done. If issue has an associated branch and MR, close issue right after merging the MR and deleting the branch
 - Important for tracking purposes
 - **Manually:**
 - close button on issue details page
 - move to “closed” column on an Issue board (more details later)
 - **Automatically:** 
 - Link MR to issue with magic phrase in MR description: “Closes #123”
 - There are other magic phrases that do the same thing, like “implements #123”
 - The shortcut for creating a MR from an issue adds the magic phrase for you
- Move
 - Button on bottom right of issue detail page.
 - Copies issue to new project, leaves original issue in original project, but closes it in original project
- Delete
 - **Pencil icon (to edit issue) > Delete issue**
 - Usually you want to close, not delete
- Bulk issue edits
 - Go to list of issues
 - Click **Edit issues**
 - Select issues to edit
 - Edit metadata fields in right pane
 - Click **Update all**

DEMO: Lab 5 tasks:
- Organize, promote, and link issues and epics

---
# Quick actions

- **Keyboard shortcuts** for common GUI actions
- Some actions are *only* available as quick actions
- Enter in **discussion**: `/<COMMAND> [<VALUE>]`
- Examples: 
 - `/lock`
 - `/assign me`
 - `/assign @Soren @Kirin`
- `/` shows a list of quick actions and explanations
- [Docs](https://docs.gitlab.com/ee/user/project/quick_actions.html) have more complete descriptions
- Don’t forget `/tableflip` and `/shrug`

Notes:
- Example of action only available via quick action: time spent on an issue
- Some quick actions are also available in MRs
- When demoing quick actions, use `/promote`

---
# Description templates

- Use **Choose a template** dropdown when creating an issue
- Pre-populates issue **description** with text
- Add **quick actions** to templates to set metadata
  - `/cc @nlotz`
  - `/assign @ccowell`
- Helps **filer** by simplifying issue creation
- Helps **team** by reducing requests for clarification

Notes:
- Commonly used at GitLab
 - e.g.: template for requesting update to class slide content
 - e.g.: template for bug reports

---
# Description templates

- **Project**, **group**, or **instance** level
- Defined in repo files or settings
- Can set **default** templates
- **MRs** can also use templates

Notes:
- Template definitions are files in the following paths in a repo:
 - **.gitlab/issue_templates/<MY-TEMPLATE>.md**
 - **.gitlab/merge_request_templates/<MY-TEMPLATE>.md**
- Set default template
 - **Settings > General > Visibility > Default description template for issues >** ENTER TEMPLATE TEXT
- MR templates are stored in a different place than issue templates
- DEMO: Lab 5 tasks:
 - Create and apply a description templates

---
# Service Desk

Notes:
- The description templates you just saw are one form of automation.
- Another form of automation is the service desk.
- Customers can submit issues directly to your project via email.
- Refer to docs for more info.
- - -
More talking points:
- GitLab Service Desk lets your customers’ emails go directly to your issue queue.
- The module allows your team to connect directly with any external party through email right inside of GitLab; no external tools required. An ongoing conversation right where your software is built ensures that user feedback ends up directly where needed, helping you build the right features to solve your user's real problems.
- Use it to give customers an efficient way to email bug reports, feature requests, or any other general feedback directly into your GitLab project as a new issue. In turn, 
- Resources:
 - Documentation: https://docs.gitlab.com/ee/user/project/service_desk.html
 - Demo video: https://about.gitlab.com/blog/2017/05/09/demo-service-desk/

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 5
## Organize and perform operations on issues
In this hands-on exercise, you will: 
- Set issue metadata
- Organize, link, and promote issues
- Create issue description templates

---
# Question and answer break

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 6

## Code review and approvals
 
At the end of this module, you will be able to:

- Create merge requests and explain why they are important
- Describe the ways people can be involved with merge requests
- Understand how code changes get approved and by whom
- Monitor and use the built-in To-Do list

---
# Merge requests

- Code edits happen on **branches**
- **Merging** a branch adds its edits to main codebase
- Perform a merge using a **Merge request**
- GitLab component similar to an issue
  - Request to merge a specific branch
  - `Merge` button performs the merge
  - Shows test and scan **results** for that branch
  - **Discuss** code changes
  - **Approve** code changes
  - Specific to **1 branch** in **1 project**

Notes:
- MR has several purposes
- Why create it at beginning of work, before any work exists? 
 - So it can show test/scan results
 - So whole team can discuss code
 - Encourages transparency and collaboration
- Part of the issue/branch/MR trio, all created at same time with similar names

---
# Metadata fields for a merge request

Notes:
Walk all merge request sections, left to right:
- **Nav bar:** same as for issues
- **Breadcrumb trail:** same as for issues, but MRs use “!” as the magic character
- **Approvals:**
 - Coworkers can approve the MR, meaning they think it can be merged
 - Anyone can approve an MR
 - Can require certain people to approve it before merging
 - Can require a representative from certain group(s) to approve it before merging
- **Test and scan results**
 - Shows automated test and automated security scan results for the latest code added to this branch
- **History:** same as for issues
- **Discussion:** same as for issues
 - MR discussion focuses on code changes
 - Issue discussion focuses on the idea or priority of the work
- **Metadata**
 - Like with issues, some fields are settable with quick actions
- **Assignee:** same as for issues
- **Reviewers**
 - 0, 1, more people assigned to review the code and leave comments in the Discussion field
- **Milestone:** same as for issues
- **Time tracking:** same as for issues
- **Labels:** same as for issues
- **Lock merge request:** same as for issues
- **Participants:** same as for issues
- **Notifications:** same as for issues

---
# Assignee vs. reviewer vs. approver

- Subtle differences between roles
- No hard-and-fast rules, but suggested best practices
  - **Assignee** is accountable for MR moving forward
  - **Reviewer** is asked for feedback
  - **Approver** has authority to merge
- Use metadata for **assignee** and **reviewer(s)**
- `@mention` approver in comments when code is done
- `@mention` anyone in comments for any reason
- Experiment to see what works best for your team

Notes:
- Ideal numbers:
 - 1 assignee
 - lots of reviewers
 - small number of approvers

---
# MR approval rules

- Approval rule: MR blocked until approved by certain people
- Defines # of approvals needed from a GitLab group or list of users
  - 1 approval from *Alice*, *Bob*, or *Charles* (all are on Security team)
  - 2 approvals from anyone in the *MobileBankingApp* GitLab group
- 3 special-purpose groups provided by GitLab
  - *License-check*
  - *Vulnerability-check*
  - *Coverage-check*
- Define approval rules per MR or per project (preferred)
- 1 MR can have multiple approval rules
- Optional: **Code owners** must approve changes to certain files or dirs

Notes:
- License-check group as an example:
 - Provided by GitLab
 - Initially empty
 - Can override block on an MR that introduces an outside code library that uses an incompatible license
- Vulnerability-check group:
 - Must get approval to unblock a MR with security vulnerabilities
- Coverage-check group:
 - Must get approval to unblock an MR that reduces the % of code that is covered by automated tests
- Code owners feature requires a CODEOWNERS file in a certain place, that lists files/dirs and person or group responsible

DEMO: Lab 6 tasks:
- Set group-level merge request approvals
- Create a merge request

---
# Possible code approval workflow

Notes:
- Just one way to do it, but a good starting place. 
- **Maximalist approach**; you might not use all of these features.
- Adjust as needed for your team.
- Dotted lines are optional steps
- DEMO: Lab 6 tasks:
 - Perform code review and merge changes

---
# To-Do list

- Always-accessible in top bar
- Sortable, filterable
- Relates to issues, MRs, epics, designs
- Auto-creates entries:
  - *you are @mentioned*
  - *assigned to you*
  - *you are added as a reviewer*
- Manually create entries from inside issues/MRs/epics
- Auto-close via actions: respond to a comment
- Manually close
- Not affected by notification settings

Notes:
- Manually create To-Do entries from the right nav bar inside an issue/MR/epic
- These are just **some** examples of **auto-created** To-Do items
- Some people at GitLab use this as the exclusive way to drive their work

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 6
## Implement code reviews
In this hands-on exercise, you will: 
- Set merge request approvals
- Create and contribute to merge requests
- Perform code review and merge changes

---
# Question and answer break

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 7

## Issue boards 
 
At the end of this module, you will be able to:
- Create and configure issue boards
- Use issue boards to track work as it progresses
- Understand the differences between issue boards and roadmaps

---
# Purpose of issue boards

- What issues is the team working on?
- Who is doing what?
- Where is each issue in the workflow?

Notes:
- You’ve probably worked with some sort of tracking board:
 - Scrum (like this example)
 - Kanban
- You’ve probably used software that simulates post-it notes on the wall:
 - Trello
 - Jira
- GitLab issue boards are GL’s version of this feature
- GL issue boards are highly configurable, can be used for lots of different purposes and different workflows

---
# Issue board structure

Notes:
- **Cards/Issues**
 - Heart of an issue board is issues.
 - When creating the board, you set criteria that issues must meet to appear anywhere on the board.
 - Each “index card” in this diagram on on a board is an issue.
 - Each issue gets its own self-contained box in an issue board.
- **Lists** 
 - Columns are called “lists” or “filters” in GitLab terminology.
 - 3 lists on this board: 
 - issues in the backlog
 - issues in progress
 - issues that are done
 - To configure a board, you mostly create and configure the lists that make up the board
- **List criteria**
 - Several options for deciding what criteria put a label in a particular list.
 - We’ll look at the options on next slide
 - In this case, imagine that that we’ve configured the lists to use labels as criteria: **backlog** or **in progress** or **done** labels
 - An issue can be in more than 1 list if it matches multiple list criteria
- **Epics/swimlanes**
 - Rows represent GitLab epics.
 - Each Epic gets separated out visually.
 - GitLab docs do not refer to swimlanes! The **group by epic** switch turns on a view that’s equivalent to a swimlane.
- - - 
More talking points:
- Boards are a powerful visualizer to help you manage your work. For example, you might want to use a board to visualize your sprint or waterfall, or control your workflow.
- GitLab Boards have amazing flexibility to create Kanban boards focused on different aspects of a GitLab issue, most common being Labels and Milestones.
- You can create lists based off labels, then use a filter to filter on a timebox milestone for agile or a deliverable milestone for waterfall.
- Please note that the full set of board features is available with Premium license level.

---
# Issue board criteria

- What issues should be on your **board**?
 - Tons of flexibility
- What issues should be in each **list** on the board?
 - Only 4 possible kinds of lists

|           | **Labels** | **Assignee** | **Milestone** | **Iteration** | **Weight** | **Multiple?** |
|:---------:|:----------:|:------------:|:-------------:|:-------------:|:----------:|:-------------:|
| **Board** |      ✅     |       ✅      |       ✅       |       ✅       |      ✅     |       ✅       |
|  **List** |      ✅     |       ✅      |       ✅       |       ✅       |      ❌     |       ❌       |

Notes:
- 2 questions to answer when configuring a board
- Use almost any criteria to decide what goes on your *board*.
- More limited criteria for deciding what goes on each *list*.
- DEMO: Lab 7 tasks:
 - View and customize project level issue boards

---
# Issue board details

- Group or project level
- Can create multiple boards
- **Open** and **closed** lists provided by default
  - Open issue: “Open” status & not on any other list
  - Closed issue: “Closed” status
- Filter cards on board (separate from board criteria)

Notes:
- Default **open** and **closed** lists can be disabled
- Dragging example: drag unassigned issue to list with “assignee: Tom” criterion assigns that issue to Tom
- Two rounds of deciding what goes on your board: 
 - board criteria filter out some issues
 - filter bar at top temporarily filters out more

---
# Issue board details

- Create new issue from within a list
- Issues can be in multiple lists
- Click a card to go to the issue’s details page
- Focus mode
- See [docs](https://docs.gitlab.com/ee/user/project/issue_board.html) for more features

Notes:
- Focus mode good for team meetings and standups

---
# Dragging cards on issue boards

- Issue appears in **list(s)** according to its **metadata**
- Issue appears in **swimlane** according to its **epic**
- Drag issue ↔ between lists to change its metadata
- Drag issue ↕ within a list to change its order/priority
- Drag issue ↕ between swimlanes to change its epic
- Shift-click for bulk drags

Notes:
- DEMO: Lab 7 tasks:
 - Manage group issue boards
 - Create a new issue board

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 7
## Create and customize issue boards
In this hands-on exercise, you will: 
- Customize existing issue boards
- Organize group-level issue boards
- Create new issue boards

---
# Question and answer break

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Module 8

## Workflow best practices 
 
At the end of this module, you will be able to use GitLab PM features for 3 workflows:
- Kanban
- Scrum
- Waterfall

---
# General best practices

- Use **boards** often
- Use **templates** to ensure issue descriptions have the right info
- Call out **blocking** issues
- Use scoped labels to show **health** of WIP issues
  - *Health::On Track*
  - *Health::Needs Attention*
  - *Health::At Risk*
- Create and use **labels** as needs arise
- Set issue **weights** when possible

Notes:
- These apply no matter what workflow you use

---
# Kanban in a nutshell

*Each person takes 1 small issue.*

*When it’s done, they take another.*

---
# GitLab PM for Kanban

- 3 scoped “Status” labels: *Backlog*, *WIP*, *Done*
- 3 scoped “Health” labels: *On Track*, *Needs Attention*, *At Risk*
- 1 list per Status label
- Assign someone to every WIP issue
- Reassign health labels to issues as needed

# *------------*

- Optional: set WIP limit
- Optional: use epics to see swimlanes

Notes:
- If you have more issues in a list than the WIP limit allows, the list turns red

---
# Kanban example

Notes:
<style span="color:red;">Walk each part of this diagram:
- 1 list per label
- 1 swimlane per epic
- Each card shows issue, weight, health
- Drag cards to advance them as work progresses
- Top of each list: total number of issues and weight
- WIP list is past its 2-item soft limit
- Can create an item in each list with *(+)* button
- Named this board for the dev team

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 8
## Create and manage a kanban board
In this hands-on exercise you will create and manage a kanban board.

---
# Scrum in a nutshell

*Issues live in a project backlog.*

*Issues have weights.*

*Work happens in ~2-week sprints.*

*Issues are JIT assigned to the next sprint backlog.*

*Issue status changes as work is completed.*

*Teams learn how much they can do per sprint.*

---
# Scrum terminology vs GitLab terminology

---
# GitLab PM for scrum
## Setting up

- “Status” labels: *Project backlog*, *Sprint backlog*, *WIP*, *Done*
- “Health” labels: *On Track*, *Needs Attention*, *At Risk* 
- Make as many issues as you can think of
  - Label with *Status::Project backlog*
  - Add more issues at any time
- Make an iteration for just 1 upcoming sprint

Notes:
- Emphasize GitLab-preffered bottom-up approach as an alternative to top-down
 - Start with issue, that has to do items within the description
 - Promote issue to epic, convert to do items into individual issues within that epic

---
# GitLab PM for scrum
## Setting up

- Backlog grooming
  - Assign weights to issues
  - Prioritize project backlog
- Sprint planning
  - Assign issues to next iteration
  - Change label to *Status::Sprint backlog*

---
# GitLab PM for scrum
## During a sprint

- 1 board per iteration
- 1 list per Status label
- Track in-sprint progress with iteration burndown charts
- Store retrospective notes in Wiki

Notes:
- Only make iterations 1 sprint in advance. 
- Don’t delete old iterations
- Emphasize GitLab-preffered bottom-up approach as an alternative to top-down
 - Start with issue, that has to do items within the description
 - Promote issue to epic, convert to do items into individual issues within that epic

---
# Scrum example
## Sprint board

<img src="../gitlab/slides/images/scrum-example-sprint-board.png" width="920" height="427" alt="Scrum example sprint board"/>
 

Notes:
Walk each part of this diagram:
- Board dedicated to sprint 6: only includes issues in iteration called **Sprint 6**
- 1 list per status label
- 1 swimlane per epic
- Each card shows issue, weight
- Drag cards to change status
- Top of each list: total number of issues and weight

---
# Scrum example
## Project backlog board

Notes:
- Separate board for Project Backlog
- Board only includes issues with Status::Project Backlog label
- Only 1 list: issues with Status::Project Backlog label
- Drag them up/down to keep them prioritized
- DEMO: Lab 9:
 - Create and manage a scrum board

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 9
## Create and manage a scrum board
In this hands-on exercise you will create and manage a scrum board.

---
# Waterfall in a nutshell

*Design everything.*

*Then build everything.*

*Then test everything.*

Notes:
- Probably not used much anymore
- Lots of semi-Waterfall permutations in use
- We’ll talk about pure waterfall

---
# GitLab PM for Waterfall

- Each waterfall step has a milestone with a due date: 
  - *Design*, *Dev*, *QA*
- 3 scoped “Health” labels:
  - *On Track*, *Needs Attention*, *At Risk*
- 1 board per milestone
- Each board has 1 list per health label
- Issues move between lists if their health changes

# *------------*

- Optional: use epics to see swimlanes

---
# Waterfall example

Notes:
Walk each part of this diagram:
- Board is dedicated to the waterfall’s **Dev Stage**
- 1 list per health label
- 1 swimlane per epic
- Each card shows issue, weight
- Drag cards to change health
- Top of each list: total number of issues and weight

DEMO: Lab 10:
- Set up a waterfall model in GitLab

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Hands-on lab 10
## Create and manage a waterfall board
In this hands-on exercise you will set up a waterfall model in GitLab

---
# Question and answer break

---
# GitLab Certified Project Management Specialist Exam

- 2-part exam process 
  - Written/Knowledge
  - Hands-On/Skill

7 days to complete from 1st day of class 
[Exam instructions](https://drive.google.com/file/d/1WpkdmNPRkT9gnNDw57-2gv4Y4Hus5mTe/view?usp=sharing)

Notes:
Exam instructions:
https://drive.google.com/file/d/1WpkdmNPRkT9gnNDw57-2gv4Y4Hus5mTe/view?usp=sharing

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" height="25%" width="25%" alt="GitLab logo"/>

# Final Q&A

---
# Post-class survey

- **What can we improve? What went well?**
- Please complete our 60-second survey
- We read all survey responses carefully

</div>

`https://www.surveymonkey.com/r/proservtraining`

Notes:
- <div style="color:red;">paste URL into chat https://www.surveymonkey.com/r/proservtraining</div>
- <div style="color:red;">paste class name, instructor name, class date into chat</div>

---
<img src="../gitlab/slides/images/gitlab-icon-rgb.png" width="150" height="150" alt="GitLab logo"/>

# Thank you!

`proserv-education@gitlab.com`

`#GitLabEducationServices`