How the ZenHub Team Uses ZenHub Boards on GitHub

Here at Axiom Zen HQ, we are all familiar with traditional project management applications, such as JIRA and Trello. Many of us have used these tools extensively in prior companies and, as users, we have all had the same complaint: they take us out of our workflows!

Zenhub is a beta product that allows us to develop faster, communicate better, and release without overhead by integrating everything within GitHub, the place all our code lives in.

We are big believers in the concept of ‘dogfooding’ and our entire team – from developers to project managers and from HR to Marketing – use Zenhub throughout the day.

In this blog post I would like to share with you how we use Zenhub to build Zenhub.

Zenhub Boards – Why we Visualize our Workflow

One of the most visible features of Zenhub is the ability to associate a visual task board to every GitHub repo, built almost entirely on top of GitHub’s native Issues functionality. We call these Zenhub Boards.

The Zenhub Board can be described as an ‘information radiator’, but more than that, it provides a compelling point of focus: What are our current goals? What are our highest priority issues? Do we have any blockers? Are we on target? A great task board should provide immediate feedback to these questions. It is this extra layer of organization and transparency that we really wanted to integrate with GitHub.

We believe a visual task board is an important part of creating a high impact team. Humans are visual creatures, and an organized board allows communication of status and actionability of individual tasks for an entire project in a single instant.

By keeping all our priorities organized with GitHub Issues and the ZenHub Board, we have been able to completely eliminate the need to store a product backlog outside of GitHub.

So why not use a wall and post-it notes, you may ask? Like many modern software organizations, we have team members based all over the the world, and having a digital, visual representation of every project’s status via a ZenHub Board makes it easy for us all to stay in-sync and provides the answers to the questions above – wherever you may be!

Zenhub Boards for Product Development

When you create a Zenhub board, each “card” is a GitHub Issue, and Pipeline columns can be created and renamed to fit your specific workflow. Issues can be dragged-and-dropped between pipelines, and everything is pushed out in real-time to all other Zenhub Board viewers.

ZenHub makes it very easy to change the layout of your Zenhub Board. As we went through sprint iterations and retrospectives, we experimented with workflows and altered our layout. Currently, we are happy with the following:

Although we all fully expect this to change in the future!

Product Development Pipelines

Each Zenhub Board can be customized to fit the needs and requirements of the team using it. We’ve found a blend between traditional Agile, kanban, and GitHub Flow methodologies to work well for the Zenhub team itself — providing enough structure and information-sharing to focus activity into impact, but avoiding stifling individual creativity and drive.

New Issues
This Pipeline is the landing point for new Issues. We have a weekly triage meeting to review and prioritize all Issues in this pipeline. Anyone from the team can create an Issue at any time and know that, through this process, it will be visible to everyone. The triage meeting should always end with an empty ‘New Issues’ pipeline!

Icebox
The Icebox represents items that are a low priority in the product backlog. We don’t want to delete these and create a cycle of raising duplicate issues, so we keep them in our icebox with just enough information attached that we can pick it up some time in the future — if and when we choose to do so.

Icebox Issues should not take up a team member’s time or mental bandwidth; we find that putting ideas into the Icebox Pipeline gets them out of our heads and helps us focus on immediate priorities.

Backlog
This Pipeline is a prioritized backlog of items ready for development. The Backlog is used heavily during sprint planning meetings: the higher an issue is on this list, the higher the priority. Higher-priority items will typically have more in-depth information attached, and we keep all our use cases and requirements in the Issue comments.

In Progress
This one is self-explanatory! Each Issue in this pipeline should have an assigned owner who is responsible for its completion. If a team member decides to take on a task, she or he simply self-assigns the Issue and moves it to the In Progress column, instantly communicating to the rest of the team that the task is underway.

Review/QA
We use the Review/QA column for Issues that are open to the team for review and testing. Usually this means the code is deployed into our Staging environment and in-use by the 40+ member Axiom Zen team spread across the world.

Done
Issues in this pipeline need no further work and are ready to be closed. Having a good ‘Definition of Done’ agreed upon before work starts on an Issue is very helpful here! If there were any objectives or key metrics associated with the Issue, they can be appended prior to closing.

Product Development Milestones

For our larger projects (like Zenhub), we make heavy use of GitHub’s native Milestones feature to break up our product backlog into manageable chunks. We then use an easy filter by milestones feature on the Zenhub Boards to create powerful snapshots of our product roadmap.

Everything starts in the ‘global’ milestone, which acts as our product backlog. Issues within this milestone are almost always contained in the first three Zenhub Pipelines on the Zenhub Boards given their pre-development nature.

Each product development Sprint also has a Milestone associated. During the Sprint planning meeting, we create the new Milestone and assign to it the most important Issues from the ‘backlog’ Pipeline of the Global milestone.

Each Issue then flows through the remaining Pipeline steps until it lands in the “done” Pipeline and is shipped as part of the next releasable version of ZenHub.

Keeping a Record of Sprints

We are currently doing weekly Sprints and have found it very helpful to have a ‘master’ record of the Sprint. Initially, we experimented with the GitHub wiki, but found it was too out of sight and therefore did not hit our internal goals around visibility and transparency.

Instead, we have started creating a special Issue per Sprint, identified with the label ‘Sprint Goal’ that details all the information around the Sprint.

Information that might be included in a Sprint’s “master Issue” includes the sprint goal itself as well as specific deliverables required for its completion. Evidence metrics should be included in order to serve as an objective definition of success. A sample Sprint Issue could look like:

Keep in mind that while we record our ‘Sprint Goals’ and ‘Sprint Deliverables’ in a visible place for the team to reference, we still keep our ‘Sprint Retrospectives’ along with lot of other useful information in the GitHub wiki!

In closing

I hope this post shows you a glimpse of how we use Zenhub and GitHub to build Zenhub.

Bringing our entire product design and development process into GitHub has increased our productivity, and we hope your team can reap the same benefits once you supercharge your workflow with Zenhub – we’re looking forward to seeing what we can ship together!