Github Projects - Make Github work for you as a product manager

Github released in Q3 2021 their beta project boards, allowing users to mutualize their boards across a single organization. This, as a product manager, really made my day once I realized I could manage on a single URL all project boards I had for the different teams I’m working with. There was the sprint board, the maintenance board, the website board, the SDKs boards…

All in all, I had up to around 10 boards to manage and monitor every day.

The beta project board presents some advantages:

• It can be either like a table or a Kanban board
• It can regroup multiple single boards under a unique URL
• Issues can be grouped by any field and have multiple custom fields
• Issues can be sourced from any repository inside that organization.
• You can save views on tables with specific filters and sorts, like in Notion.

So, along with my 400 issues, I took on the heavy task of moving them all to this new board during a slow work period, last Christmas. In this article, we’ll review the fields and views I added so the whole team can feel at ease in this new organization. I hope it will help you too. Let’s go! 🚀

Creating the beta project

On Github, you can create a new project by going to the organization and clicking on Projects and then “New project (beta)”. Doing so creates a new beta project board for your organization.

From there, add all the issues on your repository you want to see on this board, whatever their repo. This will be your backlog. This can be a tedious step, depending on how many issues you have in this organization.

Add fields

Next, the fun part: organize your views so you can switch between them and organize your sprints.

I personally chose to have 11 views, but they don’t all serve the same purpose even though they’re all important:

• Backlog is the original view, where all issues go when they first are added to the organization.
• Roadmap is our product roadmap, a Kanban board, with quarters acting as columns. Here I have a long-term view of where I want the product to go.
• Milestones is the view where items from the roadmap are split into multiple issues and represent the product’s Epics. Those Epic issues are bundled in sprints and the “Next up” view shows a list of issues ordered by sprint. I like to plan and organize the next few sprints so I can have a longer vision of what should be happening in the next few months and can coordinate with the marketing and sales team with an approximate release date.
• Current sprint shows in a Kanban-style board all issues that the product team is currently working on.
• 🛠️ Maintenance view is all the bug and refactoring issues we have and that we tackle every 2 weeks after a sprint is done. The maintenance week act as a “pressure relief” valve and is entirely dedicated to those issues, so we can tell our users the issues they’re encountering will be handled soon. Check out the maintenance week and how it helps to effectively manage tech debt here.
• Open PRs ensures we don’t have PRs that have been waiting for a long time and receive the proper attention.
• Issues/Assignee is a view for some of our team members that are not entirely concerned by our sprint organization, like our designer or our SRE team. They can simply go to that view and work on tasks affected to them without troubling themselves about the week we’re on.
• The 🪴 Garden is a special view for our Lead dev, who tackles more technical issues.
• SDKs is the view for our 12 SDK maintainers. Here are added all issues from our SDKs repositories. They know they can come in there and handle them. More about our SDK organization in this article.
• WWW is our kanban board dedicated to our website.

I’ve introduced new fields and added filters to some views so our issues can be better bundled and automatically organized. The previous project boards allowed us to add a milestone, assign a user and add labels. Now, we can add much more information like:

• Priority: 🏖️ Low, 🤔 Medium, ⛰️ High and 🌋 Urgent
• Sprint: 2 weeks followed by a break week.
• Points: represents the average estimation given by our developers for each issue on a 1-21 scale, 1 meaning the task can be done while having coffee, chatting with your pet/kid/spouse and with construction noise in the background, 21 meaning it should be split up and cannot be done in a single sprint. More about our issue estimation technique in a next article.
• Subject is the view the issue should be added to, for instance, the App, the WWW, the 🪴Garden, the SDK or the maintenance views. Only one subject per issue can be chosen.
• Quarter is for the roadmap to show the issue on the correct quarter/column.

Plan your sprints

Plan your sprints with the Sprint field. Go to the project settings, find the “Sprint” icon and add iterations. Iterations can be from any length of your choice. Plan breaks in between by clicking in between each iteration. You can edit any time slot by clicking on the dates.

How are issues added to our sprints?

Devs usually toggle between the Current Sprint, Maintenance and Open PRs views. Our lead dev spends his time between his 🪴Garden and the Open PRs while I navigate between all of them, taking an item from the roadmap at the time, splitting it into multiple issues with a common milestone and prioritizing them so the MVP can be worked on first and the “nice to have” features on latter sprints.

When creating a new issue, I ask my teammates to maintain the following organization as much as possible:

Mandatory:

• Assign it to the organization’s project so it appears on our boards (that’s the only caveat I had trouble with on this feature: new issues are not automatically added to the project, learn how to find these issues here).
• Assign it a subject, it can be “Maintenance”, “WWW”, “APP”, “SDK”, “🪴Garden” or “Roadmap”.

Non-mandatory:

• Assign a milestone, these are used as sub-categories and help prioritization, depending on our roadmap.
• Assign a priority, using the Priority parameter, please assign “Urgent” wisely.
• Sprint, Points, and quarters are left to the lead dev, CPO and PM to organize the sprints.

Find issues that are not yet on your project

While we wait for a feature to automatically add a new issue from the repository to the project, you can find all issues that are not yet attached to the project by going to your repo list of issues, and searching for is:issue is:open no:project.

Continue your research:

Learn more about Github’s beta projects in their documentation or in this video:

See all feature requests that have been added to Github’s feedback repository so you know if any feature is missing and is planned to be added in the future.