Follow Zube on Twitter

Keep Your Zube Cards in Sync with GitHub Column Labels

The new Column Labels feature lets developers on GitHub easily see and manipulate a card’s category in Zube. When you turn on the Column Labels setting for your Workspace, Zube will create special labels on each of your project’s GitHub source repositories for every column. When you move a GitHub backed Card from one column to another on Zube, the GitHub Issue will be updated with the corresponding column label.

There’s more good news! The Column Labels feature works the other way around as well! If a Zube column label is added to an Issue on GitHub, Zube will automatically move the Card to the appropriate column.

A GitHub Issue showing a Zube Column Label

You can enable Column Labels for GitHub backed Cards on the Workspace Settings page. Also, it is highly recommend that you to install the Zubebot when using Column Labels for a seamless experience.

We hope the new Column Labels feature makes it even easier for your entire team to plan, track, and manage your projects whether they are on Zube or on Github.

Send Pull Requests Where They Belong

We’ve introduced two new workflow options for handling GitHub pull requests in your Zube Workspaces. You are now able to assign which column open pull requests should go to when they are added to a Workspace. You can also decide whether merged pull requests should be automatically archived or left in the Done column.

To change the default column for open pull requests, head to the Workspace Settings page and open the column editor. Simply drag the purple Open Pull Request indicator to any column with the state Open and any GitHub pull request that enters that Workspace will automatically be added to that column.

Workspace settings showing Open Pull Request default column

Zube will now leave your merged pull requests in the default Done column for your Workspaces instead of automatically sending them to the Archive. If you’d like to restore the old functionality of automatically archiving your merged pull requests, you can turn it back on in the Workspace settings by clicking the button underneath the column section.

When you have to ship on time

Sometimes you have a deadline that you just have to hit. The problem is that deadlines are challenging to hit because people always underestimate how long it is going to take them to build something, especially software. To account for this, a trick that some people use is to take their best estimate and then double it to get the “real” time it will take. I’ve used this method myself to varying degrees of success, but I never felt very good about it. And what about Hofstader’s Law?

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Fortunately, there is a better way to make estimates, and it goes by the name of planning poker. When I first heard about planning poker I thought it was a gimmick. However, upon closer inspection, it turns out that underpinnings of planning poker are well supported by science.

The Four Planning Pitfalls

The reason planning poker results in more accurate estimates is that it reduces the effects of The Four Planning Pitfalls. Let’s take a look at what those are:

The Four Planning Pitfalls:

  1. People are terrible at estimating absolute numbers (hours)
  2. Larger tasks are more difficult to estimate than smaller tasks
  3. Team members are susceptible to anchoring
  4. Individuals are influenced by the planning fallacy

Here’s how planning poker helps mitigate the effects of The Four Planning Pitfalls:

  1. Estimates are in terms of the relative complexity between tasks
  2. Estimates are distributed on an exponential scale
  3. Everyone shows their estimates at the same time
  4. The final estimate is reached by consensus

The mechanics of planning poker

Before we dig into the science, let me briefly describe the mechanics of planning poker so that we’re all on the same page. The way planning poker works is that each team member is given a set of cards that have the following numbers on them 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

A planning poker deck of cards

The team leader describes a work item (story) to the team and asks them to choose the card that best represents the complexity (size) of the task. Each team member places their card face down in front of them. Once everyone has placed their card on the table, the cards are turned over revealing their choices. If the cards all show similar numbers then you’ve successfully estimated the task and the process is complete. However, if there is a big difference between the highest and lowest card (like a 2 and an 8) then the people who selected those cards are given the floor to defend their choices. With this new information, the team then repeats the estimation process. The process is repeated until a consensus is reached. In practice, when the cards only differ by one number, lets say a 3 and a 5, then just pick one and move on.

Why planning poker works

Not all tasks are created equal

The reality of the world is that people are terrible at estimating how long as task will take to do. Luckily, while people are terrible at making absolute estimates, they are pretty good at choosing which task is bigger, task A or task B. To take full advantage of this fact, you should get your team to start thinking in relative terms instead of absolute hours. The common way to do this is to ask your team to give each task a relative complexity score called “points” instead of estimating how long an individual task will take to do.

Once your planning session gets rolling, it is easy to assign each task a certain number of “points” based on its complexity. However, before you get rolling, you’re going to have to arbitrarily give the very first task a certain number of points. As a rule of thumb, pick a medium size task and just assign it the value of 5 points. You can then use this first task as a baseline for figuring out the relative complexity of your next task, and so on. Ranking the cards in terms of complexity will produce an ordered list that is much more true to real life than if the tasks had been ranked by hours.

Now, with all of the tasks ranked by complexity, you can figure out how long all the tasks will take to do by determining how long it takes your team to complete a “point”. While I won’t discuss the details here, you can figure it out pretty easily by tracking the total number of points your team is able to complete each week (which you can get from a velocity chart) and also how many unplanned points are added per week (which you can see on a burnup chart).

As as an aside, it is also worth pointing out that while it’s important to try to determine how long it will take your team ship a new feature, it is also important to determine which tasks are the most complex, at least as far as efficiency is concerned. Teams are most efficient when they tackle tasks with the highest priority and lowest complexity first.

Uncertainty grows with the size of your estimate

How much does a car weigh? I know it weighs a lot, but I don’t know the exact number. I’d guess that a car weighs somewhere between 3,000 and 5,000 lbs. Now, how much does a semi-truck weigh? I’m not sure of that either, but I’d guess somewhere between 30,000 and 50,000 lbs.

As you can see from my example, my range of uncertainty was 2,000 lbs for the car and 20,000 lbs for the truck. Making estimates like this doesn’t feel weird to me all. It seems natural to allow more leeway for the semi-truck. In general, when people make estimates they’re thinking “well it’s probably that amount ± 25%”. What they’re subconsciously doing is acknowledging that uncertainty grows with the size of their estimate.

To reflect this fact, your team should make their point estimates on an exponential scale. The scale that’s usually used for planning poker is a modified Fibonacci sequence, which takes into account that there is a wider range of error for larger guesses. The specific numbers are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. To check if this scale makes sense, let’s use the same intuition we used above and see what ± 25% is for each of the numbers.

EstimateWhat you mean (-25% to +25%)
0.50.375 to 0.625
10.75 to 1.25
21.5 to 2.5
32.25 to 3.75
53.75 to 6.25
86 to 10
139.75 to 16.25
2015 to 25
4030 to 50
10075 to 125

Yup, looks pretty good. It make sense that there is a real difference between 2 and 3, for example, but no meaningful difference between 12 and 13.

As an aside, I wouldn’t worry about the large numbers 40 and 100. They are really just included to indicate that a task is too large. In practice, I’ve never actually seen a task what was assigned 40 or 100. If a task is that large, then it should be broken down into smaller tasks that are easier for the team to accomplish in bite sized chunks.

Anchoring: good for ships, bad for decision making

Anchoring is a cognitive bias where people base their decisions too heavily on the first suggestion that’s made. Anchoring is fascinating because everyone is susceptible to it. Even if you are an expert software developer or PM, you’re still heavily influenced by the first suggestion you hear, even if that suggestion is clearly wrong. I highly encourage you to read the wikipedia article on anchoring.

No Anchoring

Fortunately, anchoring is easy to circumvent by making your choice in isolation. This is why planning poker has cards. Cards make it easy for your team members to hide their choices. There are obviously other ways to accomplish the same thing. For example, everyone could just write down their choice on a piece of paper and show it to the group at the same time. And for what it is worth, you don’t need to be in the same room to do it. You can just as easily do it over video chat or instant message. The important part is to eliminate anchoring by allowing everyone to make up their minds without being influenced by someone else’s choice.

You think you’re better than you actually are and it’s not your fault

Everyone is susceptible to the “planning fallacy”. The planning fallacy is the tendency for an individual to underestimate the complexity of a task that they are planning to do themselves. However, people don’t make the same mistake when asked to estimate how long it would take someone else to do the same task. The interesting thing about the planning fallacy is that experts are not immune from it, even when confronted with historical data showing that they had previously underestimated the time they needed to complete similar tasks.

To minimize the effects of the planning fallacy, it is important to get estimates from people who are not going to do the work themselves. A word of caution here, if your team is closely aligned, then they are still susceptible to the planning fallacy as a whole, meaning that they would give longer estimates if a different team was going to do the same work. So in reality, even when your team reaches a consensus, their estimates are still going to be too low. Over time, you’ll be able to track how much your team’s estimates differ from reality and you should be able to account for their optimism.

Start making better estimates today

Planning poker is a proven technique for producing better estimates. I’d recommend giving it a try as it will most likely work for your team as well. If you team is too hip to do planning poker with the cards, then don’t use the cards. The important part is that you embrace a technique that avoids The Four Planning Pitfalls so you can make better estimates and ship your product on time.

Always know what happened

We are pleased to announce that event Timelines have been added to your Cards, Tickets, Epics, and Sprints. You’ll also find that the comments section has been consumed by the Timeline so both events and comments are displayed together. Since the Timeline feature is brand new, some events that happened a long time ago may not show up, but going forward all of your important events will appear in the Timeline as soon as they happen and will live on for posterity.

A card showing its event Timeline

Enhanced Burndown and Burnup charts

You’re not doing Agile project management correctly unless you reevaluate your project’s requirements when new information becomes available, which usually comes from carefully listening to your customer support team or your developers. In an ideal world, once your team has started a Sprint, the scope of the Sprint would be set in stone and all you’d have to do is complete all the tasks methodically. However, in practice, it is often necessary to add tasks to a Sprint that is currently underway. To account for this, the Burndown and Burnup charts now have more accurate ideal trend lines. It’s no problem to add or remove cards from a Sprint, even after it has started. The ideal trend lines might start to look a little strange, but you can be confident that your product will ship on time if your team’s progress is on track.

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!