How we’re using GitHub Projects to standardize our workflows and stay aligned

As a product manager working across multiple engineering teams, I spend a lot of time planning out and tracking the work involved for our upcoming releases to GitHub Projects. Each release comes with a set of cross-functional tasks that need to be completed, such as providing public documentation and performing a phased rollout, and there are many teams and stakeholders that need to be kept up to date of progress along the way to ensure it is successful.

To best collaborate across diverse teams, we use GitHub Projects to plan, manage, and provide updates for each release right next to our code. Project templates allow us to standardize our process and create a reusable framework to ensure the success of each release, with status updates keeping stakeholders informed of progress along the way.

Using project templates as a reusable framework

Creating and using project templates ensures each upcoming release can get off the ground running quickly and is smooth sailing all the way to general availability. We don’t want to spend time manually setting up a new project or creating tasks for each release (given there are a lot of them!), so we build templates to track repeatable tasks and establish best practices for our teams.

There are two kinds of templates we use to get started:

• Built-in templates, provided out of the box, are a good starting point for common projects and use cases. They serve as great examples we can either use directly or build off of and tailor to our needs. The “Team planning” and “Roadmap” templates are just a couple examples that have provided inspiration for how we manage our team backlogs and communicate our quarterly roadmap.
• Organization templates can be created by members in the organization and come with preconfigured views, custom fields, workflows, insights, and draft items. These are great for standardizing all of our organization’s project management workflows and can be created from scratch, copied from another project, converted from an existing project, and even recommended within an organization.

While we have created templates that our teams use for our own feature release management, let’s dive into how teams across all of GitHub are utilizing project templates!

How GitHub uses project templates

At GitHub, we build project templates to standardize our workflows across the organization and create consistency within and across teams, with a growing collection of over 50 templates that we have built to help us accomplish our repeatable tasks. Some of these templates include:

• Product Feature Release to help teams kick off a new release and track cross-functional tasks across teams such as engineering, product, design, documentation, and social. This template is specifically helpful for my day to day and is used and refined as we learn from each release.
• Program Roadmap to help teams build and visually communicate their upcoming plans in a single place.
• GitHub Copilot Adoption Blueprint to help onboard and ensure the success of teams adopting and utilizing GitHub Copilot.
• Engineering Onboarding to provide a cohesive list of tasks that should be completed in the first weeks and months for a new engineer joining the organization.
• Bug Tracker to triage new bug reports that come through for first responders, prioritize fixes, and track progress so we can provide ongoing updates.

Our template collection at GitHub continues to grow and expand to more use cases across teams and departments, so it’s one click and you’re off!

Staying aligned with project status updates

I use our “Product Feature Release” template to plan out and manage each upcoming release, so once we have officially kicked off and are working through our issues and pull requests, I want to make sure that all involved teams and stakeholders are kept in the loop on the progress along the way. To do this we use project status updates to keep everyone aligned on how the release is progressing, when it is expected, and any risks that we should be aware of, all in a single place in the project.

Status updates allow us to provide short and regular summaries on the progress of the release, such as the Status, Start date, and Target date. We tend to provide additional high-level details such as:

• A brief summary of progress over the last week using @ mentions.
• Relevant metrics on early adoption and performance.
• Potential risks or upcoming challenges we should be aware of.
• Dependencies on other teams and workstreams that may impact our target release date.

By providing regular updates, we have a feed of history so our stakeholders can follow along and understand why the target date shifted, why it shifted from On track to At risk, or what the cross-functional dependencies are.

I can then see the status of all of my relevant work and projects all in a single place, so I can drill in to understand more details.

The bottom line

We are continuing to build our collections of project templates at GitHub to help us standardize our processes across teams, spanning from feature releases, employee onboarding, and building and sharing our roadmaps. We encourage teams and organizations to build their library of project templates to help establish and share best practices, and share status updates on their projects to easily communicate progress of those tasks with their teams and stakeholders all in a single place.