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.
