In part one of this series we looked at the pervasive problems around collaboration and how GitLab was built to resolve those challenges both in and out of the software development space. In this second part we take a detailed look at how our marketing teams used GitLab for project management.
When we jumped in to using GitLab for project management, we did it in a big way. The Just Commit marketing campaign which launched in January 2019 is a good example of how the marketing team uses GitLab features like issues and epics.
"It was our first integrated campaign, and if you're not familiar with what that means, it's basically landing a single message across all channels," says Jackie Gragnola, marketing programs manager. “So using social media, digital marketing, all of our content, our website. and in doing so, it was involving a lot of different team members."
Since there were so many stakeholders involved, it was unrealistic that something like a Google Doc could provide the infrastructure necessary for efficient and transparent collaboration. Jackie migrated her kick-off document from Google Docs over to GitLab. "It was the first test into using epics to give the high-level information and then organize the group into a single unified vision for what this campaign would become," she explains.
The Just Commit integrated campaign epic included the JustCommit label, as well as campaign goals, personas the campaign is targeting, links to recorded meetings, and more.
The Just Commit ancestor epic also included details such as UTM tracking links, a list of teams and DRIs involved in the campaign, and a timeline of key dates and deliverables in the lead-up to the Feb. 18, 2019 launch.
A level below the ancestor epic are child epics, which were organized by areas of action items. Some examples include organic search, webcasts, emails, and events; messaging and positioning, etc.
Examples of some of the child epics for the Just Commit integrated campaign.
The Just Commit label that was created was tagged to issues related to the campaign. It is simple enough to get a high-level overview of what issues are related to the Just Commit campaign by searching for the label.
In order to dig deeper into the different categories of work, you’d look at the issue list within the different child epics. The issue list functions essentially as a list of what needs to get done, and provides a good overview of what’s left to accomplish on the list.
This is an example of the issue list from the strategy and design child epic.
Inside each issue is a DRI and a due date. The due dates were important not just to stay ahead of deadline, but also because there were a lot of dependencies baked into the integrated campaign.
"We couldn't work on the content until we knew what the message was, and we couldn't work on anything related to digital marketing until we had the designs approved," says Jackie. "So, this just kept us organized by saying what we needed to get done by what dates and kept us up-to-date on the timeline that would help us hit that delivery date."
By using GitLab features such as ancestor epics, child epics, issues, and labels, the Just Commit integrated campaign kept all stakeholders updated on their progress and accountable for their deliverables.
How product marketing uses GitLab
Tye Davis is a technical marketing manager and he uses GitLab for managing product marketing projects.
Use issue boards to get a global overview of work
Tye works primarily within the product marketing project, which is housed in the broader marketing group. Just like we saw in the Just Commit integrated campaign, there are various ancestor epics, child epics, and issues housed within this project.
The issue board view is a useful way to visualize and organize all the issues and activity happening within a specific group or project. Viewing an issue board is simple enough: Just select boards under the issues tab to see all of the issues within a specific group, or to narrow the scope select a specific project. But building one is another matter entirely.
It is important to think strategically about the level at which you build your issue board, because that will impact how much information is rolled up into the board.
"You have to think about where your work lies and where you should be building your issue boards in epics," says JJ Cordz, senior marketing ops manager. "As an example, in marketing ops we presently work across departments so we do a lot of with sales ops, biz ops, sales in general, and all of those are individual projects and groups. So our issue board is actually built at this highest level (i.e., marketing group level) because we need to pull in everything else."
But not every team is as integrated as marketing ops. Sometimes building an issue board at the team level, instead of the group or project level, makes the most sense for your workflow.
The technical marketing team has its own issue board, and it is sorted by labels. The labels it uses are uniform across the marketing group to indicate the status of a particular issue – status: plan
, status: WIP
, status: scheduled
, or status: review
. The labels automatically change when a particular issue is dragged between label lanes.
The use of these labels and the different team boards that live within the product marketing group allows anyone to take a look at the status of both individual issues and larger projects.
Team boards
Another option to configure an issue board is to base it on teams and sort based on an assignee. The team board view sorted by assignee allows you to see what each team member is working on.
“We create boards based on assignee. This allows us to see who has what issue and what they're working on," says Tye. “Maybe your manager just wants to see what the team's working on or you're being a collaborative Agile team and want to just see what everyone's doing or what you could work on together."
Tracking progress
There are two main options for measuring work progress from a project management perspective: milestones and burndown charts.
Milestones are time-bound and track work output based on a specific timeframe (e.g., Q1 FY20 – a four-month period). When creating an issue, you can assign it to a specific milestone.
Burndown charts reflect all the issues that are completed within the specific milestone. Once the time period (e.g., Q1 FY20), is up, you move any remaining and new work over to the next milestone (e.g., Q2 FY 2020).
Relating to GitLab customers
While the marketing team and other teams across the company use GitLab as a project management tool, the majority of our customers are engineers that use GitLab as an Agile planning tool for developing code.
We can still relate to our customers through our use of issues and merge requests to make changes to the handbook, publish blog posts, among other activities in different repositories within GitLab.
Whether you’re an infrastructure engineer, product marketing manager, or even an editor for the GitLab blog, the GitLab product functions as a sophisticated and customizable project management tool where collaboration and efficiency are baked into the function and design.
Watch the video from GitLab Contribute in New Orleans to see an overview of how GitLab can be used for project management, plus more on using GitLab for integrated campaigns and product marketing.
Cover image by Startaê Team on Unsplash.