GitHub Workflows

Set Up My Task Boards

About ZenHub Boards: Kanban for GitHub

ZenHub adds advanced multi-repository boards into GitHub. Inspired by kanban boards – a flow-oriented approach to development – ZenHub's boards present a simple yet incredibly robust picture of your software projects.

Think of task boards as rich information broadcasters about your entire software organization. They allow you to track GitHub issues and pull requests end-to-end through the release cycle.

Instead of tickets or sticky notes, ZenHub's Boards are made up of your existing GitHub data: issues and pull requests. Let's look at the anatomy of a ZenHub Board:


Default pipelines

ZenHub Boards come with six default pipelines to start with: New Issues, Backlog, To-Do, In Progress, Done, and Closed. It's a standard kanban-like setup that suits most projects, but can also be customized to suit more unique workflows.

Regardless of how you customize a board, GitHub issues and PRs should move left to right as they get closer to completion. But it's not only the job of a project manager: in a high-functioning team, everybody participates by dragging issues as they progress through the development cycle. The key to making it possible is a well-organized board.

Here's a quick overview of what each pipeline means.

  • New Issues: New issues land here automatically. You should drag (triage) them out of here as soon as possible.
  • Backlog: Backlog issues are not a current focus, but you will act on them at some point. If they don't have a GitHub milestone, you can consider them part of your “product backlog”. Once you add a milestone, they become part of your “sprint backlog” (that is, the tasks that you'll complete in an upcoming sprint.) The process of keeping this pipeline organized is known as “backlog refinement”.
  • To Do: Issues here should have a good amount of detail, like estimates and requirements, since they're your team's current focus. Tasks here will flow into the In Progress pipeline, so order them by priority and add Assignees.
  • In Progress: This is the answer to, “What are you doing now?” Ideally, each team member should be working on just one thing at a time.
  • Done: If you ask three people what “Done” means, you might get three different answers. That's why it's so important to have a discussion as a team about your “Definition of Done”!

Refining Your Product Backlog

If you're seeking a GitHub issue tracker, Boards can be one of your most powerful tools – but they're only as useful as you make them.

A product backlog represents feedback from multiple sources, like other developers, sales, business development, but most importantly, your users. It's your job to take in that feedback, prioritize it, manage it, and work it into the future of your product.

Without a process, your Boards can become clogged with inactionable feedback and a lack of focus. In contrast, a well-managed backlog leads to a more efficient and focused team. The result is a better product, and one that your customers actually want to buy.

Here's our recommended sprint-based workflow that can help bring clarity to your product.

  1. New feedback and ideas automatically land in the New Issues pipeline.
  2. The product owner reviews each issue and figures out if it's actionable.

    Note: “Product owner” refers to whoever makes the ultimate call as to what is built and when. Typically, it's a project or product manager.

  3. If you intend to complete an issue but it's not ready for development (i.e. it needs more detail or the team has no capacity for extra work), the issue is dragged the Backlog. Issues here don't yet have a milestone. You'll add one at the beginning of a sprint.
  4. If it's a valuable issue but you have no plans to tackle it in upcoming sprints, “freeze” it in the Icebox pipeline.
  5. If the issue isn't going to get done, just close it. If it's really that important, you can always re-open it later!
  6. Is an issue ready for action? At this point, your team should have added details, like acceptance requirements, and a user story (a short feature description as told from the perspective of user benefit.) Your engineers should have added an estimate. Once an estimate and a milestone have been attached to an issue, it's formally part of your “Sprint Backlog” (the stuff you'll tackle in the next sprint.)
  7. When the sprint begins, simply filter the Board by milestone to see what needs to be done. Team members can drag tasks off the top of the backlog to indicate they're being worked on. Simple!
Next Lesson:
I want to visualize my GitHub workflow
You’ll learn…
  • How to build your perfect workflow with connected repos and custom layouts