Did you know that you can use LiquidPlanner for, or in addition to, bug tracking software?
Many LiquidPlanner customers do both, depending on the nature of their team and the systems that are already in place, among other things. A little over a year ago, Liz Pearce wrote an earlier version of this blog post, Bug Tracking in LiquidPlanner, and we still get a lot of questions on the topic. So, here’s a refresher for you, with the latest information and screen shots. We know that some customers are using our API to integrate with GitHub, Jira, and Bugzilla, to name a few. Now, you can use LiquidPlanner Webhooks too, which can make integration even easier. Internally, we use LiquidPlanner exclusively for filing, tracking, verifying, and collaborating on bugs and incidents. We do all this without any outside integration.
Our Support and Sales teams learn about issues from customers and prospects via phone calls and emails, in addition to fielding incoming tickets with Zendesk. We also hear about new issues through Tweets, and Facebook comments, but those are resolved immediately, or just need quick replies. But when you have the kinds of bugs and issues that need help from our development team, that’s where LiquidPlanner comes into play.
Why only LiquidPlanner? We want to track bugs along with the rest of our work, from within our schedule. Bugs need to be assigned, estimated, and prioritized with our project work, based on severity and impact. We fix bugs (new and existing) in every release of LiquidPlanner, and since LiquidPlanner is the one system we all look at every day, it doesn’t make sense for us to track them in a separate system.
We think the Inbox is the best place to track new bugs. Some tasks may be created directly in the UI, but for the most part we take advantage of email integration. We’ve all added the email address of our workspace Inbox to our address books so that it’s handy. Anything that needs attention can then quickly and easily be sent in. We create business rules with our team, and do our best to prepend the subject line of emails with “BUG:”— and then give a hint as to what it’s about, since this will become the task name.
Here’s what our Inbox looks like:
What happens with the email? As mentioned above, the subject of the email became the task name. The body of the email (including screenshots, repro steps, or error messaging) was saved to the Notes section of the task. Any documents you attached to the email were automatically uploaded to the Documents section. This ensures that that all relevant information stays with the task as it goes through our workflow.
Processing the Inbox: As you can see in the above screenshot, we also use the Inbox to collect feature requests and other to-dos for our various teams. It fills up fast. To handle this volume, we meet twice weekly to triage everything, and empty the Inbox. During these meetings, we review every new item relatively quickly as a group – estimating, assigning, and prioritizing as we go. Some bugs get moved into the current sprint, others get pushed into the staging sprint, or out to the backlog. If a new bug is assigned to a developer, they get notified through email and it shows up in their list of Active Tasks.
Bug bashing: We typically structure the work within each sprint into several major categories. One of which is “Bugs.” This lets us view, analyze, and report on the bugs as a group —separate from other tasks like new features, or tech debt. However, as you can see in the image below, the amount of work associated with bugs gets complex – and hence our interest in tracking them in conjunction with our other project work!
Customization and organization: We use custom fields to indicate the feature area and severity of the bug. When prioritizing or doing other editing, we select the appropriate custom field. This is great for both filtering in the plan, and for reporting purposes too.
Collaborate! All comments, collaboration, and updates are stored in the task. This includes references to specific customers who may have been affected and conversation about repro steps. We also have LiquidPlanner integrated with our source control system, so that code check-in notifications are automatically added as comments to the task (or, the bug).
Sometimes this information can pile up, but since the most recent comments are added to the top of the list, it’s pretty easy to stay up on the latest happenings of each bug. Perhaps a concise summary or the most important information will be put into the “Brief Description” section of the edit panel. For new documents that have been uploaded to the task, don’t forget that you can sort by uploaded date.
Finally, once the bug has been fixed, we assign it back to the creator (or a tester) for verification. By simply switching ownership of the task, we can move it through an informal workflow that doesn’t bog us down in process. The person who created the item is also notified by email that they have a new assignment.
Once the fix has been verified, the item is marked “Done” and becomes part of our fully searchable archive for later reference. Voilà!
LiquidPlanner might not match all the features of a dedicated bug management system. But what it might lack in dedicated features it makes up for in ease of use, simplicity, and integration into our other processes.