How we deal with bugs
A bug is a task like any other. We used to have a nice system that consisted of changing labels (depending on the state of the bug), but we’ve recently changed our workflow and made it more agile.
We now have two projects:
- ActiveCollab Planning — for all suggestions, ideas, wishes, dreams, and reported bugs.
- ActiveCollab Production — everything we are working on or will work on in the near future.
Splitting tasks in two project helps us focus on work at hand and separate what we’d like to work on from what really needs to be done.
It’s easier to work on some tedious task that has a high business value when a fun trivial feature is not constantly in front of you — out of sight, out of mind.
Every reported bug starts as a task in the ActiveCollab Planning project in the “Inbox” task list. When our QA confirms the bug, it goes to the “Bugs Confirmed” task list. It gets a label “Bug” and a corresponding business value label.
We use comments in the task for discussion, as well as for communication between our developers and our users (our support being the middle man).
Once we decide to work on the bug, we move the task to the “Backlog” task list in the ActiveCollab Production project. Each task must have three labels: business value, complexity, and type of work.
After that, we treat the bug like any other task:
- The product manager decides what to work on (based on the labels),
- we move the task across task lists (depending on their stage),
- complete them,
- include the fix in our release notes,
- and inform the user who reported the bug.
This system is less complex than our previous (this one doesn’t include a flowchart), and it’s more in line with the agile workflow. So far, it works great.