Huboard: A Kanban Board For GitHub

Agile development teams using GitHub repositories usually have work in two places, as issues or defects in their github repositories and as user stories and epics in their agile work management tool. Often a plugin or bridge is used to make the work flow from the business view to the Github repository. Although this satisfies most compliance requirements and allows the development team to work where they are comfortable, it doesn’t provide the UNIFIED information radiator that promotes a common conversation among all members of the team, including the stakeholders. If you are using a physical Kanban board and other physical radiators you may not encounter this problem. For distributed agile teams, however, I’ve found it to be a common one.

REALLY WORK IN GITHUB – HUBOARD

I recently explored an application that displays GitHub issues and defects, as well as pull requests, from your repositories in Kanban work board format. In this post we will refer to aKanban Board, NOT the Kanban methodology. A Kanban Board is just an information radiator that shows where the work is in the development cycle. The Heroku application,Huboard,  has pros and cons for an agile project team, but overall can provide a lightweight, easily adopted solution to managing a sprint backlog for a distributed team.

 WHAT HUBOARD DOES

  • Provides a virtual agile work board WITHIN GitHub. No plugins or bridges to other applications.  Everything is right there.
  • Allows you to decide what work will show up on the board. Work begins in the backlog by default OR you use a feature that allows you to designate what goes on the board. This keeps things clean.
  • Allows you to define work stage columns with any name you desire. Backlog is hidden behind the left arrow and appears when clicked.
  • Uses GitHub labels and milestones. Those work “stages” are labels in the GitHub repos. You can apply them to almost anything and still use labels the way you used to within GitHub. Milestones provide an easy view on the left-hand side of how work is categorized. This is particularly useful for epics.
  • Updates with drag and drop. In the Kanban board view you can drag and drop work into different columns, updating the labels within GitHub.
  • Allows access to the GitHub issue directly by clicking the #Number from the Huboard view.
  • Honors user permissions. Users only see issues for repos they have permissions for, even if more repos are connected to that Huboard.
  • Shows multiple repos on one Huboard. An organization can show all or a few select repos on a Huboard.
  • Provides basic, high-level progress on issues at the milestone level.
  • Has an active and responsive developer, RaughRyan, in Austin, Texas. I submitted several requests that were entirely project manager centric. Although Huboard’s current user base is mostly developers, Ryan caught the vision and responded to my issues quickly and thoroughly.
  • Actively iterates. Here are a few of Ryan’s recent blog posts on Huboard that highlight its recent iterations:

WHAT HUBOARD DOESN’T DO

  • Estimation tools or mechanisms. You’ll have to find a way to do this within your issues and repos.
  • Detailed metrics or reporting. Look elsewhere for that.
  • Combine milestones with the same name. As a PM, I’d like to be able to combine milestones for multiple teams. For example, we use the Milestone label to denote an epic. If I have a community team working on the epic Flash training, the dev team and QA team doing the same, they all have separate repos in GitHub.  I’d like to be able to aggregate those milestones and show a progress bar from that point.  The issue is in his backlog and I’m sure he’ll get to it like he has my other feature requests.

MY HUMBLE OPINION

Would I use it again?
Yes. With an open source project or a development heavy project with a technically savvy product owner, yes. With a multi-track project with larger teams and a demand for dashboard-type reporting, then no. I’d go with a system like Sprint.ly with GitHub integration to pull requests.

Can non-developers “get it”?
Yes. The interface, once set up, is understandable and relatively intuitive. You will probably need a developer’s assistance to set it up.

How long does it take to set up?
About ten minutes.

Would I Reccomend it?
If your priority is simplicity and a digital work management tool for a distributed team, Huboard may be for you. It’s fast to set up, has a low learning curve, and will either become your Kanban board or help your team determine exactly what they do and DON’T want out of a digital work board.

VITALS RECAPPED

  1. Overview in Plainspeak: GitHub issues made awesome
  2. GitHub Project: https://github.com/rauhryan/huboard
  3. Developer: https://github.com/rauhryan
  4. Website: http://huboard.com/
  5. Twitter: https://twitter.com/Huboard
  6. Blog: http://lostechies.com/ryanrauh/author/ryanrauh/
Advertisements

One thought on “Huboard: A Kanban Board For GitHub

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s