Bug Tracking in LiquidPlanner
Monday, February 8, 2010 at 3:02PM |
Liz Pearce 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 (still in beta) 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 saved to a tasklist called “UNTRIAGED,” which is the central holding place for new bugs, feature requests, ideas, and tasks until we can process them (Figure 1). This tasklist lives in the “Prioritize” view of LiquidPlanner; each item is also put into a folder on the “Organize” view for proper categorization.
Figure 1
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” tasklist 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 collaborate page of LiquidPlanner, ensuring that all relevant details stay 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 prioritized 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!
Figure 2
Figure 3
All comments, collaboration, updates, and files associated with the bugs are stored on the collaborate tab. 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à!
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.
What could we add to LiquidPlanner to make it a better tool for tracking bugs in addition to your regular project work? We have some ideas (such as custom columns & item types) but we’d love to hear yours.









