Marketing Project Management Guidelines

Sub Pages

  1. Organization - Groups and Projects
  2. Labels
  3. Epics
  4. Milestones
  5. Managing Commitment
  6. Issues
  7. Boards

Marketing Project Management Guidelines

Marketing uses GitLab for agile project management including groups, projects, epics, roadmaps, issues, labels, and boards. Read through the documentation on each of these GitLab features if you are unfamiliar.

Integrated Campaigns

Marketing Departments collaborate to produce Integrated Campaigns. An Integrated Campaign is a communication effort that includes several campaign tactics such as blog posts, emails, events, advertisements, content on about.gitlab.com, videos, case studies, whitepapers, surveys, social outreach, and webcasts. An Integrated Campaign will have a campaign theme that summarizes the message we are communicating to our market.

Active integrated campaigns

Active integrated campaigns

Have a new campaign idea? Make a suggestion

Project Management Processes

We cultivate a deep understanding of our own product by using GitLab to manage our planning, collaboration, and execution of Marketing activities.

The latest Project Management recommendations can be found here from FY21-Q2 Agility Project

Milestones

The latest recommendations for Milestones from FY21-Q2 Agility Project

Weekly Sprints

Within the www-gitlab-com repo (parent repo to Marketing) there are weekly milestones, which some teams use plan a weekly sprint cadence. Each of these sprints begins with “Fri:**” for the Friday upon which that sprint ends, making them searchable in a list here.

Each week on Monday, any open MRs and issues still assigned to the previous week’s milestone are bulk moved forward to the next week, and the previous milestone is closed out. This is a manual process currently performed by Danielle.

Groups and projects

The latest recommendations for Groups and Projects from FY21-Q2 Agility Project

  1. The Marketing Group houses all marketing projects.
  2. Labels should be created at the group level so they can be used in all projects within Marketing group.
    • Labels should not be duplicated in individual projects. It creates board/tracking conflicts.
  3. The following are the approved marketing projects, CMO approval is needed to begin a new project.
  4. Issues should be logged in the team project ultimately responsible for completing requested work. (i.e. If SDR needs list uploaded -> issue created in Marketing Operations project).

Issues, Milestones, and Epics

The latest recommendations for Epics and the latest for Issues from FY21-Q2 Agility Project

  1. Each issue represents a discrete unit of work with a deliverable. For example 1 2 3
  2. Every MR should have an issue so that it can be tracked on issue boards.
  3. Milestones represent units of work to be completed within a specific time frame, sometimes referred to as sprints. They are comprised of multiple issues that share a common due date, and help break large projects into more manageable parts.
  4. Epics represent projects that comprise multiple issues. (Don’t use “meta” issues for this purpose. If you have an existing meta issue you can promote them to epics using the /promote quick command.)
    • Epics live at the group level (e.g. issue from multiple marketing projects can be added to an epic.)
    • Epics are labeled with a group label of the team that owns the epic.
  5. The top 3-5 strategic initiatives are tracked in epics using the CMO label. (Don’t apply the CMO label to other epics.)
  6. Roadmaps are used for time-based display of epics with a start and end date. (for example, events and time-based campaigns.)

Boards and Labels

The latest recommendations for Labels and the latest for boards from FY21-Q2 Agility Project

  1. Each team has one or more boards to track ongoing workstreams.
  2. Generally, create a board for each function. (For example PMM has boards for Sales Enablement, Analyst Relations, Customer Relations, etc.)
  3. Each board uses a standard set of columns/labels so that folks can easily understand what is happening on another teams board.
  4. The board labels use group scoped labels with mktg-status:: and one of four statuses. Status labels should be used on all issues within the Marketing group:
    • mktg-status::plan - work that is proposed, in an exploratory state.
      • To exit the plan stage the work must be assigned to a DRI.
      • DRI accepts responsibility for the task by changing the label from mktg-status::plan to mktg-status::wip and creating an merge request (MR), if appropriate. The plan status is optional, as issues that don’t require formal planning can be opened and labeled mktg-status::wip.
    • mktg-status::wip - work in progress that has been accepted and assigned to a DRI.
      • Work in this stage should not be merged.
      • Merge requests (MRs) should be prepended with WIP:. At GitLab we allow reviewers to start reviewing right away before work is complete.
      • Use MVCs: At any time, if the work is complete enough that merging would be better than what current exist the issue should be labeled with mktg-status::review and WIP: should be removed from the title.
    • Optional*: mktg-status::review - work has been completed enough that it is ready for formal review and approval.
      • Work that is approved can be either merged or scheduled.
      • The review status is optional.
      • Work that doesn’t require review can simply be merged/closed.
    • Optional: mktg-status::scheduled - work that is complete but should be scheduled for a future date.
      • Scheduled status is optional as not all work will need to be scheduled.
    • closed - when work is delivered the issue should be closed.
  5. Don’t duplicate status labels at the project level. Use group labels (at the Marketing Group level) as much as possible.

Department Labels

Each Department within Marketing can have “additive” labels - meaning they are used to enhance the tracking and workflows for that respective team. These “additive” labels are used in conjunction with the broader Marketing labels. The Department label usage is documented on each of the respective handbook pages:

Default Issue Text

All of the projects within the Marketing subgroup include default issue text to ensure the Department labels are applied consistently and broader adoption of the global Marketing labels.

Using Default Issue Text

When a new issue is opened in any project, the issue description will contain a small snippet of text applying that teams’ label & Marketing scoped mktg-status::plan label.

’’

  • If a template is chosen, a message will appear confirming you want to change the text w/in the issue description, click Apply Template and continue as normal

’’

Updating Default Issue Text

The default text is minimal and generic. Any team can make the collective decision to update the text. Access to modify the text may be limited based on group/project permission level, if you do not have access to the General settings section, please reach out to @mktg-ops via slack. Please note this is not an issue bot there is no dynamic functionality. The default issue text applies to all issues opened within that project and the text should be broad enough to encompass a roles within that team.

  1. Navigate to project to be updated
  2. Left side menu, hover over the wheel widget (last icon) -> Select General
  3. Scroll down & select Expand next to Default Issue Template
  4. In the text box you can add any markdown formatting & modify the text. The text that has been added included several lines above it, so it may appear to be a blank box. Scroll down &/or expand that text box to see complete text.
    • Please do not delete the labels section.
    • Label section can be updated to include more labels &/or switch the Department label
    • Important to leave the mktg-status::plan label in that section
  5. Once edits have been made, click Save changes. The changes be applied immediately to any new issue opened.
    • Does not affect already opened issues.

If you have any issues &/or questions, please reach out to the MktgOps team (@mktg-ops) via slack.

How it all fits together

Figuring out how where and how to create a board, epic, label can be confusing. The following diagram is a very high level example of how it all fits together. If there are questions please ask in the #mktgops slack channel (*must be GitLab team member for active link).


Epics project management guidelines

Background

Epics provide a way to organize and manage a set of issues and sub-epics that share a strategic theme. In addition to logical grouping, epics enable project managers to perform higher level planning and build a roadmap with visual status tracking.

Key things to know

  1. Epics are defined at the group level.
  2. Epics can be made confidential.
  3. Epics can contain both issues and epics as children.
  4. Epics can be used as a filter in issue lists and issue boards.
  5. Epics provide visibility on child epics, issue statuses, and the roadmap timeline (Gantt chart).
  6. An epic is visible on a roadmap view if it contains a start or due date - all marketing roadmap here.
  7. Child epics are also visible on a roadmap view, nested under their parent, when they have a start or due date.
  8. The roadmap view provides a timeline of epics and their completion status based on aggregate issue weight completion for issues linked to the epics.
  9. The roadmap view is available on the individual epic and the group page under Epics > Roadmap. The group page view provides additional filtering, sort order, and timeline units for display.
  10. An issue can only be the child of a single epic.
  11. Epics can have multiple child epics up to a depth of seven levels in total.

Known Limitations

  1. Epics cannot be created from templates (issue) however, there are three workarounds.
    1. First - Epics Can be created from an issue that is promoted to an Epic (in this case, an issue template could be a substitute for an epic template).
    2. Second - The mixture of issues related to an epic can be templatized in a spreadsheet and uploaded to populate the issues related to a given epic. See this epic template overview - note for collaborative epics that span multiple GitLab projects/teams: with this process, for the total number of projects/teams the issues span, you will need to complete that number of uploads of the spreadsheet, broken out by project/team.
    3. Third - Include code for the epic in the relevant handbook page to be copy/pasted, with issuable template hyperlinks. See this handbook page for an example.
  2. Epics do not have an assignee.
  3. Epics cannot be created in projects (issue).
  4. Epics cannot be cloned (issue).
  5. Epics cannot contain issues from above their parent group (epic).
  6. Feature request: calendar view (issue).

Guidelines

Use the roadmap view for high-level overview

The roadmap view can serve as the single source of truth and as a high-level overview to effectively understand the strategic themes, OKRs, marketing projects, and campaigns the team is working on.

Issue and Kanban boards project management guidelines

Background

Boards in GitLab make it possible to visualize and manage lists of issues which can be defined by one of three ways: Labels, Team members, and Milestones.

Key things to know

Board usage

  1. First, a common use of boards is in the Kanban style of visualizing work

Issues project management guidelines

Background

Issues are a core building block in GitLab that enable collaboration, discussions, planning and tracking of work.

Issues are typically used to

  • Support a Discussion on a specific topic
  • Define requirements for a new feature
  • Organize work on a specific deliverable
  • Manage a specific workflow (i.e. requesting access to a system, getting commitment from another team, etc)
  • Planning an aspect of an event or a campaign.

Because issues can serve so many purposes and roles in GitLab, understanding where they exist and how to best utilize them is incredibly important.

Labels project management guidelines

Background

Labels are a powerful, flexible way to categorize epics, issues, and merge requests.

When applied appropriately and consistently, Labels enable GitLab users to discover, filter, manage, and report on issues, projects, or epics.

Key things to know

Label hierarchy

There are two types of labels in GitLab:

Managing Commitment

Background

Teams and individuals are often asked / requested to work on multiple efforts, across the company. For example,

  • An event, needs booth branding or messaging
  • A campaign, needs positioning/messaging and perhaps a gated white-paper
  • A new whitepaper or infographic needs design input
  • A campaign, needs a customer case study
  • A team wants an analyst inquiry

While it is possible to use issue assignments or labels to track simple tasks and assignments, in an organization of scale, there are challenges.

Marketing Groups and Projects guidelines

Background

GitLab helps to organize teams and work through a hierarchy of Groups and Projects.

Key things to know

Groups can contain other groups (subgroups) and projects.

groups and subgroups

Groups and Projects are both similar and fundamentally different, which can be confusing when using GitLab

Feature Groups Projects Comments
Epics X Collection of related sub epics and issues in a strategic theme
Roadmaps X Graphical view of epics over time
Milestones X X Burndown charts of a time boxed period
Issue Insights X X Analytical view of issues and merge requests
Labels X X Flexible ability to tag issues, epics and Merge Requests
Issue Lists X X Lists of all issues, enables bulk updates
Issue Boards X X Visual boards of issues grouped in lists
Issues X An item of work, a deliverable, a request, a discussion
Repositories X A set of files that are under version control
Merge Requests X The discussion/management of change to files under version control
CI Pipelines X Automation of build and test of files / code that is being changed

Graphically, this illustrates the difference between groups and projects:

Milestones project management guidelines

Background

There are two concepts of time-based tracking in GitLab.

  • Milestones: useful for tracking the progress of multiple issues across a specific time period, and when planning and managing epics.
  • Iterations: useful for planning agile or agile-like sprints to capture action items to be completed within a specific time period.

Milestones

Milestones are a great way to track the progress of multiple related issues across a specific time period. With milestones, you can see how fast issues are being completed in that time period (burndown chart), and you can view the issues grouped by labels, and grouped by status (unassigned, assigned, and completed)

Last modified August 8, 2024: Add HeadingLink rule and fix errors (424f73d2)