Marketing Project Management Guidelines
Sub Pages
- Organization - Groups and Projects
- Labels
- Epics
- Milestones
- Managing Commitment
- Issues
- Boards
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
- The Marketing Group houses all marketing projects.
- 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.
- The following are the approved marketing projects, CMO approval is needed to begin a new project.
- 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
- Each issue represents a discrete unit of work with a deliverable. For example 1 2 3
- Every MR should have an issue so that it can be tracked on issue boards.
- 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.
- 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.
- The top 3-5 strategic initiatives are tracked in epics using the
CMO
label. (Don’t apply the CMO label to other epics.)
- 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
- Each team has one or more boards to track ongoing workstreams.
- Generally, create a board for each function. (For example PMM has boards for Sales Enablement, Analyst Relations, Customer Relations, etc.)
- Each board uses a standard set of columns/labels so that folks can easily understand what is happening on another teams board.
- 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.
- 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.
- Navigate to project to be updated
- Left side menu, hover over the wheel widget (last icon) -> Select
General
- Scroll down & select
Expand
next to Default Issue Template
- 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
- 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).
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
- Epics are defined at the group level.
- Epics can be made confidential.
- Epics can contain both issues and epics as children.
- Epics can be used as a filter in issue lists and issue boards.
- Epics provide visibility on child epics, issue statuses, and the roadmap timeline (Gantt chart).
- An epic is visible on a roadmap view if it contains a start or due date - all marketing roadmap here.
- Child epics are also visible on a roadmap view, nested under their parent, when they have a start or due date.
- The roadmap view provides a timeline of epics and their completion status based on aggregate issue weight completion for issues linked to the epics.
- 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.
- An issue can only be the child of a single epic.
- Epics can have multiple child epics up to a depth of seven levels in total.
Known Limitations
- Epics cannot be created from templates (issue)
however, there are three workarounds.
- 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).
- 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.
- 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.
- Epics do not have an assignee.
- Epics cannot be created in projects (issue).
- Epics cannot be cloned (issue).
- Epics cannot contain issues from above their parent group (epic).
- 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.
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
-
First, a common use of boards is in the Kanban style of visualizing work
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.
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:
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.
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 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:
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)