Follow Zube on Twitter

A design that materialized from our obsession with usability

We didn’t sit down last week to give Zube a fresh new look. All we wanted to do was to make the cards on the kanban board easier to read. But once we started, we quickly became obsessed with how good design could make it easier for you to manage your entire project. Here’s an overview of what we improved.

The kanban board

Must see more cards! We got rid of the space between the cards within their categories so they butt up against each other and form a column. Not only do more cards fit on the screen, but they are also easier to read because the new design eliminates grid illusion .

Redesigned kanban board showing filter sidebar

We also moved the board filters from the top of the board over to a sidebar on the left. What’s more, we made board filtering more powerful by adding the ability to filter on priority and creator! It’s now easier to filter out the noise and focus on high priority issues.

The issue manager

The issue manager has always been a super powerful way to manage your issues (hence the name). You can quickly filter and search across your entire project and perform bulk actions, even if your project is made up of multiple repositories. What’s been missing, until now, was a design that highlighted just how powerful the Issue Manager really is, so the new Issue Manager design is all about data density and scannability. Each issue only takes up a single line with the most important information up front. Basically, it’s an awesome table :)

The new Issue Manager design

Create a custom workflow for your kanban board and sprint board with customizable columns

It’s now possible to customize your columns on Zube. Up until now, Zube had a standard set of columns for a basic Agile workflow. In this latest release, we have added the ability to customize your columns by changing their title, adding or removing columns, and by specifying default columns for your new cards and closed cards.

The column editor

You can customize your board columns by going to the new column editor found on the project settings page. You can get to any project’s settings page from the homepage or from the left sidebar. Once you’re on the project’s settings page, you can remove any column you wish by clicking “Remove” at the bottom of each column. You can also add columns and edit their attributes.

Column editor on the Project Settings page

Column attributes and markers

Once you’re editing the columns you can change the column’s attributes, including the name, state, and status. You can also change the which column is used as the default for new cards and closed cards, and which column marks the beginning of the sprint board.

State (open or closed):

A column’s state attribute can be open or closed. Any cards that are added to the column will be opened/closed on Zube and on GitHub. So, for example, if you change the state of your “In Review” column to Closed, then whenever you drag cards into the In Review column, the cards will be closed on Zube and on Github.

Status (New, Queued, In Progress, In Review, and Done):

The status attribute indicates which stage of the workflow the columns represent. These statuses are used to track the progress of cards through the workflow. When cards are add to a column, they will be given the same status as the column. Zube Tickets will automatically track the status of their linked cards, and update their own status accordingly. We’ve also enhanced the Issues Manager so you can find cards with a particular status!

Column markers (Default New, Default Done, and Sprint Backlog)

We’ve also made it possible for you to specify which columns you’d like to have special properties. If a column has the Default New marker, then any new cards created on Zube or GitHub will appear in that column. Similarly, the Default Done marker indicates the column where closed cards will move to automatically when they are closed on GitHub. Finally, there’s the Sprint Backlog marker. The column with the Sprint Backlog marker is the first column of your Sprint Board. All columns to the left of the sprint backlog are global columns, meaning that they will always be visible on the sprint board no matter what sprint you’re looking at. The sprint backlog, and all columns to the right of it are local to the sprint, meaning they will only show cards on the actively selected sprint. And as always, cards in the sprint section of the sprint board are automatically sprinted and trackable via the burndown chart.

Happy customizing!

Manage all of your GitHub repositories together

We’re super excited to announce support for multiple repositories. You can now manage multiple GitHub repositories under a single project, and since we’ve also reworked sprints, the Issue Manager, and Tickets, the benefits are huge!

Projects with multiple GitHub repositories

It’s easy to create a new project that’s backed by multiple GitHub repos. All you have to do is select more than one GitHub repository when you create a new project. It’s as simple as that. If instead, you want to add a repository to an already existing project, that’s no problem either. Just head over to the project settings page and you’ll see a list of available GitHub repositories. You can also merge two currently existing projects together!

Project settings page showing how to add additional repositories

The Kanban Board

Once you’ve created a project with multiple repositories (sources), you’ll see a sources selector on the Kanban Board. You can select one or more repos (sources) and the Kanban Board will update accordingly. Oh, btw, we’ve also included some performance tweaks in this release so your Kanban Board will load quickly and remain very responsive no matter how many GitHub issues your project has!

Kanban Board highlighting repository source selector

Sprints and the Sprint Board

Like the Kanban Board, you’ll find a GitHub repo source selector in the filter bar at the top of the page. Since a sprint is scoped to a project, and since a project can now have multiple repos, your sprints now show the work being done across all your repos! Similarly, your burndown chart will roll up your current progress for the entire project, or you can toggle which sources your want to display on the chart.

The Issue Manger

The Issue Manager lets you filter/search/sort your GitHub issues for a project on Zube, which means, wait for it… the Issue Manager now supports multiple repositories! That makes the Issue Manager super powerful. You can filter/search/sort across all of your repositories at the same time to find exactly what you want. We’ve also enhanced the Issue Manager’s filters so you can now choose issues or PRs (or both), see open and closed cards at the same time, and of course, choose which repository you want to filter on. And since the Issue Manager is now so powerful, we wanted to give you a way to grab your data and manipulate it however you like, so we added the ability to export your results as JSON!

Tickets

Tickets are now scoped to projects… um, I feel like a broken record at this point… which means that you can link cards from different repositories to a single Ticket. Like always, the Ticket will track the linked cards and notify the Ticket owner as the status of cards change. What’s new is that the Ticket owner will remain up to date even if the Ticket involves work being done across multiple repos!

New ways to manage your GitHub Issues

This product update has many new features and improvements. We added a Kanban Board, Sprints, and multiple assignees on a single card. We also changed the layout of the Board and renamed it to the Sprint Board.

The Kanban Board

Zube’s new Kanban Board has all the bells and whistles you’d expect on a kanban board and is real-time synchronized with GitHub Issues. The layout of the Kanban Board is structured to support an Agile workflow out of the box. The Kanban Board has a standard set of categories to indicate the stage of your issues as they move through the software development process. There’s a filter/search bar at the top of the board that lets you drill down and display only the issues you’d like to see. The Kanban Board supports both GitHub issues and pull requests and you can toggle which type of cards are displayed (issues and/or PRs).

Kanban Board showing a project overview

Sprints

Zube now has clearly defined Sprints. Sprints are core to the Agile scrum methodology, and are really useful for scoping what’s important for your next product release. Sprints have been a core part of Zube from day one, but now sprints are more powerful and more flexible. While you don’t have to use sprints to get tons of value out of Zube, we suggest you give them a try! You can create and edit sprints by navigating to the Sprints page, which you can get to from the navigation sidebar under the “Sprint Board” section.

TIP: In Agile, the purpose of a sprint is to timebox your work. Sprints typically last between one week and one month depending on how your team likes to work and what you’re trying to accomplish. Milestones, on the other hand, are best used to mark the completion of a stage of your development, which means that milestones are often larger and more encompassing than sprints.

Sprints let you scope your work

The Sprint Board

After you create a sprint you can use the Sprint Board to manage your issues. Just a heads up, if you were using milestones as sprints before this release, we automatically created some sprints from you, but that won’t happen from here on out. The Sprint Board allows you to focus on one sprint at a time and makes it easy for you to bring up new sprints. At the top of the Sprint Board is the start date, the end date, a sprint selector so you can choose which sprint you want to display, and a progress bar that displays the current progress that has been made on the sprint in terms of number of open and closed issues.

The Sprint Board lets you focus on what's important

The sprint selector is located at the top of the Sprint Board, and not with the other filters, because it does not affect the Inbox or Backlog columns (the two gray columns to the left of the Sprint Board). While the filter/search bar at the top of the page will affect cards in all of the columns, the sprint selector only affects cards in the Sprint Board section. This gives you the ability to easily populate your sprints by dragging cards from the Inbox or Backlog to any column on the Sprint Board since dragging card onto the Sprint Board automatically adds the card to the currently selected sprint.

After you’ve closed a bunch of cards and the sprint had come to an end, you can head back over to the Sprints page and close the sprint. If you have any open cards on a sprint when you close it, you will be prompted about what to do with them, either move them to the Backlog column (recommended), or just remove them from the sprint but leave them in their current categories. After a particular sprint has been closed, it will no longer show up on the Sprint Board.

Miscellaneous improvements

A lot of improvements found their way into this release, I’m just going to list them out here:

  • Cards can have multiple assignees (up to ten).
  • We’ve added a shortcut for assigning and unassigning yourself on cards: ctrl + click (command + click) on a card will assign it to you and ctrl + shift + click (command + shift + click) will remove you.
  • The Sprint Board has a filter/search bar.
  • You can display PRs on the Sprint Board.
  • We added a navigation sidebar that can be toggled by clicking the “hamburger” icon located just above the sidebar in the page header.
  • There’s now the option to “Disable Automatic Card Management”. This option is found on the project settings page and will make it so Zube no longer moves your cards around for you. For example, if you have “Automatic Card Management” enabled, and you open a card in the Backlog and give it a sprint, then Zube will automatically move the card to the Ready column for you. If you don’t want things like this to happen, consider disabling “Automatic Card Management”.
  • Cards with assignees can exist in any column. So, for example, you can now have a card in the Backlog with an assignee.

An Agile Project Management Workflow Just Using GitHub Issues

Although GitHub Issues doesn’t have many of the features that you’d normally want in a project management system, you can still use Issues to create a lightweight Agile workflow. All it takes is a bit of finesse and some self imposed structure.

Agile Components

These are the core components of an agile system that you can implement using GitHub issues (you might want to skip ahead if you’re already an agile ninja).

Stories (a.k.a User Stories)

Stories are the smallest unit of work to be done for a project. The goal of a story is to deliver a unit of value to the customer. In Agile-land, common syntax for writing stories is:

As a <type of user>, I want <some goal> so that <some reason>.

Sprints

Sprints are fixed-length iteration cycles, usually lasting one, 2 or 4 weeks. The goal is for the team to deliver a working piece of software by the end of the sprint (a potentially shippable increment).

Sprint Backlog

The sprint backlog is the collection of work that is scheduled to be tackled during a sprint. At the beginning of the sprint, the team decides what work they should do during the sprint and moves those stories from the global backlog to the sprint backlog. Stories in the sprint backlog should be organized by priority so the team can pick off the top tasks as they work through the sprint.

Global Backlog

The global backlog is a prioritized list of work (stories) that has not been scheduled to be completed. As new work comes in, it gets added to the global backlog and prioritized. In an Agile workflow, the development team pulls from the backlog as opposed to a manager pushing work onto the developers. The goal is to keep the backlog as small and as organized as possible.

Mapping the Agile Components to GitHub Issues

Now that we’ve laid out the Agile components, here’s how you can implement them in GitHub Issues.

AgileGitHub
StoriesIssues
SprintMilestone
Global BacklogOpen, Unmilestoned and Unassigned Issues
Sprint BacklogOpen, Milestoned and Unassigned Issues
Stories Issues

If you make an issues the same way as you would make a story then you’ve got this one in the bag.

TIP: One nice thing about stories that isn’t often adopted with GitHub issues is that stories have a consistent syntax. Feel free to abandon the typical user-focused story titles if that’s not your jam but it does make life better to have a style guide for issue titles!

Sprints Milestones

Unfortunately, GitHub doesn’t have sprints. Instead, if you want to group a set of issues together you have to use milestones. Luckily, milestones on GitHub have start and end dates, so they can be a surrogate for sprints since they fulfill the requirement of having due dates and allowing you to group issues together.

Sprint Backlog all open, unassigned issues that are on a milestone

GitHub doesn’t have a place to store your issues in a way that resembles a proper sprint backlog, but that needn’t stop you having one in your mind’s eye. All you need to do is remember that any issue that is on a milestone, is open, and is not assigned to anyone is in the sprint backlog. You can view you sprint backlog in GitHub using their issue search. Search for all the open and unassigned cards for any milestone and the resulting list is your sprint backlog.

TIP: Priority is a bit of a problem here. Normally you’d like to be able to arrange your issues so that the more important issues are at the top of the list. Since this isn’t possible on GitHub, you can use labels as a hack. To do this, create a set of priority labels (P1, P2, P3). If you’re uncertain of how many to create, just make P1, P2, and P3. As new issues come in, label them with a priority. Then when it’s time to decide what to work on, you can use GitHub’s issue search to filter by your priority labels.

Global Backlog all open, unassigned issues that are not part of any milestone

The concept is the same as the sprint backlog. You can use the GitHub issues search to find only those issues that are open, unassigned, and not on any milestone. This is your global backlog. Once again, use priority labels to indicate precedence.

A Basic Agile Workflow

Our Agile workflow will have five stages: global backlog, sprint backlog, in progress, in review, closed. Cool? Let’s go!

The Global Backlog

All new issues should go to the global backlog which means they should be unassigned and unmilestoned. Everyday, the team lead should look over the new backlogged issues and assign them a priority. Remember, in order to find your global backlog issues, use the GitHub issue search to display open issues with no milestone and no one assigned.

The Sprint Backlog

Next, it’s time to decide what to work on so you should create a new milestone on GitHub. If due dates are your cup of tea, give the milestone a due date. As I said above, one, 2 and 4 weeks are common durations of a sprint. It really depends on how your team like to work and what you’re currently building.

As a team, work through the issues in the global backlog and add the appropriate issues to the sprint backlog. You move issues from the global backlog to the sprint backlog by milestoning the issues. It’s pretty easy to just do on the fly when you come across an issue that you want to work on this sprint cycle. Remember to leave the issue unassigned, or you’ll inadvertently skip the sprint backlog, which is not cool in Agile land.

TIP: As you build up your sprint backlog, update the priority labels on the issues to reflect their priority relative to the other issues in the sprint backlog. This indicates what tasks the team should be working on first. Also, if you want to add story points to the issue, now’s the time to do it! Create another class of labels for your points and use those to weight your issues.

PRO TIP: When to label? In general, using labels to indicate the status of an issue in the pipeline is a bad idea. It’s difficult to keep the label up to date with the actual status of the issue. Bad data = lots of noise = irritated team. If you’re feeling tempted to use labels for the status of an issue, it’s probably time to add a proper project management tool to the workflow.

In Progress

When an open issue is assigned to someone, that means the issue is in progress.

Once your sprint begins, your team starts by pulling tasks off the sprint backlog, starting with the issues with the highest priority (and the lowest point values if you want to hyper-optimize your flow efficiency). When someone grabs a task, they assign it to themselves to indicate the work is in progress. It’s best if your team members only have things assigned to them if they are actually working on them. This way the team knows what everyone is working on and what issues are still available for them to bang out.

In Review

Moving issues to the review stage starts by opening a pull request. Give the PR a descriptive title that fits with your team style guide and reference all the relevant issues. Something like, “Adds widget to new feature - closes #1, closes #2” is awesome because when the pull request is merged, those referenced issues will be closed as well. Make sure the milestone of the pull request is the milestone you are using for your current sprint, and remember to assign the PR to the reviewer.

Closed

Once a pull request has been merged, you move all the resolved issues to closed. If you referenced your issues correctly in your pull request, your cards will automatically be marked as closed when the pull request is merged. Leave the milestone and assignee set on the issue as a record for later reference.

Party!

Ideally, the team should have code that’s ready to ship by the end of your sprint. Any open pull requests for the sprint should either be merged, closed or moved to the next milestone. Any open issues from the sprint should either be moved to the next milestone (if it’s in progress) or back to the global backlog by unmilestoning and unassigning the issue.

You finish your sprint by closing the milestone. Set the milestone state to closed and leave any notes about the sprint in the description section of the milestone. Some good things to record here are number of issues that had to be pushed to the next sprint (and point values), what was accomplished and what was not, and any problems that came up. Then, party!

Here’s a handy chart for the state of your issues in each stage

Gloabl BacklogSprint BacklogIn ProgressIn ReviewClosed

open

unmilestoned

unassigned

open

milestoned

unassigned

open

milestoned

assigned

open

milestoned

assigned

pull request reference

closed

Shameless plug: If you’re already doing an Agile workflow on GitHub and you’re looking for something more powerful, give Zube a try!