GitHub Enterprise for the Azure DevOps User Part 2 - The Boards

In this series of posts, I am comparing GitHub Enterprise (GHE) to Azure DevOps and giving Azure DevOps users an idea of how things are done in GHE.  The first post focused on comparing the organizational configuration of the two tools.  In this post I will show how work is managed in GHE compared to Azure DevOps.

GHE has two ways to group and manage work that can be used separately or together.  Milestones are a way to group issues typically in some time based period such as a project phase or sprint.  Projects can be used to group work designed for a continuous flow through a project board.

Milestones can also be used within a project board to provide visuals and a way to filter the cards displayed. In the following example, Sprint 20 is a Milestone and selecting it will toggle displaying only the Sprint 20 cards.

Projects can be created at the organization, user based, or created within a repository.  From an enterprise stand point, I think most projects would be created at the organizational level so this post will focus primarily on the organizational level projects.  There are 5 primary options and options for your project board including the ones below or choosing no template.  The automated templates are designed to update the board when the workflow changes in code.

Projects in Azure DevOps are the primary container for all artifacts including teams, all work items, repositories, builds, and releases.  Whereas in GHE, the repository is the primary artifact.  As I discussed in the previous post, a project typically represents something that has an end date.  GHE's product based approach is better.  A project is essentially the project board in GHE and an Azure DevOps project has multiple project boards for each team and at each backlog level.  

GHE boards can be customized.  Columns can be added and modified.  Cards can include tasks through mark down with card progress and overall project progress indicators.  One unique feature to the GHE project boards is the ability to automate the moving of cards through the boards as code changes are promoted through the development workflow.   Some board features that are only found in Azure DevOps include swimlanes, defining definition of done (DoD), Cumulative Flow Diagrams, and automatic splitting of columns to doing/done.

Work Item Types

Similarly, how Henry Ford said you can have any color Ford you want as long as it is black, in GitHub, you can have any work item type you want as long as it is an issue.  Even though everything primarily is an issue, labels allow you to classify issues different types of work.  Bug and enhancement, are two of default labels that are available, and you can add more to represent different work items types and every other way you might want to categorize the issues.  Below are the default labels for a repository.

Here is an example of how one company has created a standard set of labels to categorize types, priority, severity, functional areas, functional groups, and status.

Project boards can contain notes in addition to issues.  Notes allow for work to not clutter up the issues lists but is fairly limited.  Notes can be converted to issues if and when desired.

Backlog Levels

Backlog levels in Azure DevOps provide a way to manage work at different levels.  The default levels are Epics, Features, and User Stories.  These levels help allow different levels of the organization to own and manage the work at these different levels often providing the traceability from company initiatives (epics) to the work being done by the teams (features and user stories).  It is customizable and fairly flexible.  I saw some interesting workarounds to managing work like this with Issues through labels for both the parent and the epic itself and milestones could also be used.  A separate project board for Epics could also provide a way to manage those high level initiatives with even being able to assign those to a Leadership team.  However, there isn't any good built in behavior like the functionality available in Azure DevOps.

Sprints and Iteration Paths

As I mentioned above, sprints can be created using Milestones and milestones have a due date to represent the end date of a sprint.  However, beyond that there are no sprint planning management tools like there are in Azure DevOps.    

Teams and Area Paths

In Azure DevOps, the default way to create a hierarchy of teams to match your organization is to use Area Paths.  In GHE, you can create your team structure to match your organization structure in the Teams section.  This is great and looks like this can be used to set permissions for code reviews, etc. however it there doesn't seem to be any easy to way to assign work to a team.  One option could be to create labels for each of the teams and assign a team (label) to the card, so you could easily filter and see the work that team.

Summary

GHE has some good workflow management tools, however they are more purpose based and product focused compared to the general purpose and project based functionality in Azure DevOps.  The GHE project features are very much targeted on not getting in the way of the developer's progress.  In general, most of the enterprise project management features are only found in Azure DevOps.  In one of my next posts I'll show how we can use Azure Boards with GitHub.