Bug Tracking in LiquidPlanner [Newly Updated]

I get a lot of questions about how to use LiquidPlanner for (or in addition to) bug tracking software.  We have LiquidPlanner customers doing both, depending on the nature of their team, the systems that are already in place, etc. Several customers are using our API to integrate with GitHub, Jira, and Bugzilla. Internally, we use LiquidPlanner and only LiquidPlanner for filing, tracking, collaborating on, and verifying bugs & incidents.

Why? At the end of the day, we want to track bugs along with the rest of our work—in our schedule. Bugs need to be assigned, estimated, and prioritized alongside our project work, based on their 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.

But how, you might ask, does it actually work? Here are the gory details.

First, we have a single place to collect new bugs.  They all get sent to a Package called “UNTRIAGED,” which is the central holding place for new bugs, feature requests, ideas, and tasks until we can process them (Figure 1).  This Package has a relatively high priority position in the "Projects" page of LiquidPlanner, just under our urgent work and active sprint releases.

For us, bugs come to our attention in a variety of ways. They might be reported by a customer via email, found during the testing process or through our normal use of the tool, or sent to us as a system alert.

To get these items into LiquidPlanner, most of us use email integration. This “UNTRIAGED” Package has its own email address, which we’ve all added to our address books. When we mail an issue into LiquidPlanner, we automatically create a new “task” for tracking.

Using the subject line of the email, we can:

• Name the bug (usually it starts with “Bug: XXXXX”)
• Assign the bug to any member of our workspace
• Estimate it in any unit we want (2-4h, .5-1d)

The attached documents and body of the email (including screenshots, repro steps, or error messaging) get saved to the Details page of LiquidPlanner, ensuring that all relevant information stays with the item as it goes through our workflow.

Next, we have twice-weekly meetings to process our “UNTRIAGED” bugs. During those meetings, we review every new item, and assign, estimate, and prioritize it. 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 via email and it shows up on their personal tasklist.

We typically structure the work in each release into several major categories, one of which is “Bugs.” This allows us to view, analyze, and report on them as a group, separate from other tasks like new features or tech debt. However, as you can see in Figure 2, the amount of work associated with bugs is non-trivial – hence our interest in tracking them in conjunction with our other project work!

All comments, collaboration, updates, and files associated with the bugs are stored on the Details Page. This includes references to specific customers who may have been affected.  Sometimes this information can pile up, but since the most recent comments, documents, and links are added to the top of the list, it’s pretty easy to stay on top of the latest happenings for each item. We also have LiquidPlanner integrated with our source control system, so that applicable references/commit notifications are automatically added as comments to the bug.

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à!

We recently added new custom fields that allow us to track our bugs even more effectively. We've created a custom field for "bugs", "feature requests", etc. And, when a new issue comes up, we simply assign the appropriate custom field. This is great for filtering in the plan and for reporting purposes!

Naturally, you can argue that LiquidPlanner lacks some of the features of a dedicated bug management system. I’ll give you that. But what it lacks in dedicated features it makes up for in ease of use, simplicity, and integration into our other processes.

Comments

[Steve Reaser]

You asked at the end of the post what would be helpful to make LP more apt for bug tracking. A few things come to mind...

1) In other bug tracking software I've used, very often when I assign a case to someone else it's with a comment or question: Hey, check this out... Can you clarify xyz, etc"? The "case" can be passed back and forth with the conversation building in blog-like fashion until someone ends up handling the issue. I'm not sure if there is an easy way to do this in LP at the moment?

2) Most bug tracking software seems to display cases as a chronological list of events... initial report, clarification, proposed fix, actual fix comments, etc... by the time a bug gets to QA the tech can read through the list of events to understand the decisions that were made along the way and how to test -- but the "collaborate" are in LP is set up more as a fixed heirarchy of attachments, rather than an "event log" related to that task/case. Some way to view everything that happened to a task (including related conversation) chronologically would help (may be already possible -- I'm not sure!)

3) The other thing that comes to mind is to make it possible to see some/all things from the Colaborate tab, without having to leave the Prioritize area -- as it stands, I feel like I have to jump over to Collaborate, and then I lose sense of where I am -- lots of page refreshing and waiting. That is, the "collaborate" stuff feels somewhat disjoint or hidden from the tasks themselves, to me.

When I'm looking at a list of untriaged bugs, for example, if I could hover over the document icon and see a "preview" or summary of the collaborate content; or the latest comments or something (perhaps in a bubble like Netflix does?) then I might not have to jump around as much to understand what the bug was so I can triage it... the title/description by itself is often just not quite enough.

This type of preview feature, imho, would be helpful in many ways, not just for bug tracking. My 2 cents. :)

[Richard Frenkel]

Another thing that would be helpful for bug tracking would be the ability to turn on a unique ID. I find that clients using Jira often refer to ID-123 - a system generated ID - when sending emails about bugs or tasks.

[Mike Brown]

Can someone comment on the integration goals for the organizations that have integrated JIRA or Bugzilla into Liquid Planner and the issues they encountered?