Follow Zube on Twitter

Often your tasks are related to one another. It may be that two cards solve a similar problem and you want a quick link between them. Or maybe you have a complex card with a bunch of subtasks. Whatever the reason, you’ll appreciate the way Zube now surfaces related cards and allows you to quickly create links between them.

The related cards section

Through the UI

Every card now has a section that displays all of its related cards. Related cards are ordered by their status so it’s easy to get an overview of their progress. You can create or destroy relations from the same section as well. You can find and link an existing card with the search bar, or you can create a new one. If you want to unlink a card, just remove it from the list.

Via comments and pull requests

Zube is also smart about knowing which cards are related to one another. Zube will automatically create a link for you if you reference another card in the description or in a comment. The same goes for GitHub issues. Referencing GitHub issues on GitHub will automatically link the corresponding Zube cards.

We hope the new related cards feature will let you better organize your tasks. We’re excited to hear how you’re using related cards, so please drop us a line at team@zube.io!

Automatically triage your cards

You can now create rules to automatically send cards from the Triage to a workspace of your choice! The Triage is a great place to prioritize your work before sending it on to the appropriate workspace. However, sometimes it’s just busywork to move certain types of cards over and over again. For example, maybe every card with the label “API” needs to get done right away and should be sent to the “Backend” workspace as soon as possible. Well, now you can do just that with Triage rules!

Creating a new Triage Rule

Using Triage Rules

To create a new rule for the Triage, head over to the Project Settings. There you’ll see a tab called “Triage”. It’s easy to create a new rule, just choose any combination of source, label, or assignee and the workspace where you’d like the card to end up on. If you create more than one rule, it’s good to know that the order of the rules matters. The rules will be run from top to bottom and only the first rule that matches is applied. You can drag and drop your rules to order them however you like.

We hope that the new Triage rules will save you time and make it even easier for your teams to work together seamlessly!

Beautiful and powerful charts

Our new charts provide insights into your project like never before. There are several new charts that let you dig deep into what’s being accomplished. The truly wonderful thing about the new charts is that they give you an overview of all your data in one place, no matter where the work is being done. If you have GitHub sources linked to your project, then your GitHub data is right there too.

Burndown, Burnup, and Velocity

If you’re using sprints, and we suggest that you do, you’ll be delighted to see that we’ve added card counts to the Burndown chart. Zube will automatically track card counts for all of your sprints going forward. As a note of caution, we just started collecting card count data so don’t worry if card counts for old sprints are flat lines.

A Burnup chart with a changing goal

We’ve added a Burnup chart, which is similar to a Burndown chart except that there’s a goal line at the top instead of working toward zero. The great thing about the Burnup chart is that it allows you to see changes to your goal. In an ideal world, your goal would never change during a sprint, but in the real world it often does. With the Burnup chart you’ll be able to see exactly when cards or points were added to your sprint and by how much your goal changed as a result.

An important notion in Agile, and particularly Scrum, is the idea that your team’s efficiency should be improving over time. The first step towards increasing your team’s efficiency is to measure how much work your team is doing per week. A good way to display this information is with a velocity chart. Zube’s new Velocity chart shows the total cards or points closed per sprint so you can get a clear picture of how much work is getting done in that fixed time period. Your sprints are displayed side by side so you can make sure your team is improving over time (or at least holding steady).

Throughput and Users Throughput

Sometimes you just want to see a raw measure of what’s getting done. The Throughput chart shows you how many cards or points are closed each day. There’s a powerful set of filters that let you drill down to see just what you’re interested in.

A Users Throughput chart where each team member is a slice of the stack

The final chart we added is the Users Throughput chart. The Users Throughput chart lets you see how many cards or points each team member is closing per week. It is a stacked area chart, segmented by user, so it’s easy to see how everyone is doing over time. The Users Throughput chart makes it easy to see who is getting bogged down or which team member has really stepped up their game.

Work side by side with the development team

Zube loves developers and up to this point you needed to be a developer with a GitHub account to get the most out of Zube. That’s all changed! We couldn’t be more pleased to announce that Zube now lets you log in with Google so everyone can work seamlessly with the development team! This major enhancement is made possible by Google Login and the new zubebot.

The homepage with Google Login

Google login

You can now use Google login to access Zube, which is perfect for nontechnical team members who do not have GitHub accounts or really shouldn’t have access to your codebase. When you log in with Google, everything on Zube works just as you would expect. The only drawback is that you cannot change Zube cards that are backed by GitHub issues. If you don’t want your nontechnical team members to be able to change GitHub backed cards, then you’re all set. If, on the other hand, you do want Google users to be able to interact with all the cards on Zube, you can enable the zubebot!

The zubebot enables a frictionless workflow for everyone

Installing the zubebot means that everyone using Zube can change whatever they want! The zubebot handles the syncing with GitHub so everything will stay up to date in real time. The power of the zubebot is that it unlocks all the cards so you no longer need to give team members access to your GitHub repos just so they can manage cards on Zube. If you would like all your team members to be able to use Zube to its fullest, you’ll want to install the zubebot. We highly recommend installing the zubebot.

Tips and tricks

A couple of things you might find useful:

  1. If you log in with Google or GitHub and you are already a Zube user, we will automatically try to merge your accounts for you. You can also link your Google and GitHub accounts together by going to your user “Profile Settings”.
  2. Adding Google users to your account is slightly more complicated than adding GitHub users. First, have your team members sign up for Zube using Google. Then, you can add them to your account by searching for their usernames on the “organization settings” page. Once you’ve added the Google users to your organization, you can add them to the projects you’d like to give them access to.
  3. You can add the zubebot to your account by going to your Zube “organization settings” and clicking on the “Integrations” tab. There’s an install button that will take you to a GitHub page where you can install the zubebot. Note that you must be a GitHub organization “Owner” in order to install the zubebot.

You can find more details in the docs.

Create cards that don’t go to GitHub

For most companies, not every card on Zube also needs to be a GitHub issue. Zube now lets you to create cards without creating an associated GitHub Issue. If you later decide that your local Zube card needs to be on GitHub, that’s no problem either. You can easily add the card to a source repository by selecting one on the card’s sidebar.

Zube card showing source selector

Seamlessly manage GitHub issues and local cards together

On Zube, your local cards function in the way you’re already used to. To create a non-GitHub backed card, select ‘Only on Zube’ from the source selector when you’re creating a new card. That’s pretty much all there is to it. Your local cards will appear right next to the GitHub backed ones on the kanban board, the sprint board, and the Issue Manager. You can also add local cards to epics, tickets, and sprints, just like their GitHub backed counterparts.

How to use local cards

There are many use cases for local cards, but I’ll highlight a few.

  1. Use local cards to plan new features. Imagine you are the product owner. You know that an important part of Agile project management is to continually refine your requirements by talking to your customers. When you do this, you’ll likely get a bunch of good ideas about how the product can be improved. Your ideas are probably more nebular than specific engineering tasks, so instead of making cards that get sent to the engineers on GitHub, make local cards! You could do this right on your main board if that makes sense for your team’s workflow, but I’d suggest creating a separate workspace for product features that are still in the idea phase. Then at a future date, when you have a clear picture of what needs to get done, you can create the necessary engineering tasks, or convert your local cards to a GitHub Issues by adding a GitHub source.
  2. Use local cards for your non-engineering teams. Your company probably has a workflow that involves multiple teams. Maybe the design team and the product team spec out what they’d like to see before handing it off to the engineering team. And when those new features are ready, they need to be marketed. Local cards let your non-engineering teams use the same system as your developers without adding clutter to the developers’ GitHub repositories.
  3. Use local cards to keep private data off of GitHub. Sometimes you just don’t want certain tasks to go to GitHub. There are a bunch of reasons for this but if you’re using Zube to manage a repository on GitHub where the entire world can view the GitHub Issues there, you might not want a critical vulnerability to be public knowledge. At least until you’ve fixed it.