Developer requirements for effective bug management software

A little while back, the team at TastemakerX decided Trello was not cutting it for tracking and managing bugs. It should come as no surprise that any company requires more sophisticated project management tools as it grows and evolves. Instead of blindly rolling out github, the startup norm, we took a systems analysis approach to the problem. Below is our approach and findings.

 

Defining the Problem
—————————
Don’t get me wrong. I find Trello to be excellent for its sheer simplicity – every developer’s dream with regards to PM tools.  Its @mention functionality is poweful and the left-to-right workflow with stack-ranked cards just makes sense.  Its simplicity excels in small teams ( under around 6 people ), or for one-off or niche purposes, and does not pretend to be a full PM suite.  For anything larger, however, we found Trello lacks the hierarchical depth and standardization needed to remain effective and stay on-task.

By hierarchical depth I’m loosely referring to the Agile concepts of epic, story, and task.
Trello uses a one-size-fits-all approach to cards which can mute the importance and relative weight of tasks needing attention.
Trying to use cards at the task-level means a ton of cards can stack up in each column, versus using at the story-level means a ton of back-and-forth comments, attachments, checkboxes, and headache.
It gets even more complicated with bugs & QA feedback which often are tied to the story which needs to pass.
As with tasks, should these be checkboxes as well? What if they fit into more than one story? What if the story has already shipped?
By standardization I’m referring to common pieces of data needed in an easily scannable and filterable form.
When it comes to bugs, every developer needs certain core information: environment/browser bug was found on, steps to reproduce, and intended functionality.
With one free-form text area, it’s often difficult to parse this information quickly, and search is the only filtering medium.
This is especially a nightmare when the team is in a hurry end-of-spring – where the QA feedback can be as detailed or as “margin is 10px too tall” to “shit’s broken”.

 

Note: I highly recommend checking out some of the chrome extension plugins such as Scrum for Trello

 

 

Gathering requirements
—————————
With the overall problem in mind, we each listed our requirements for a bug mgmt solution.
To be fair, these requirements were taken from every stakeholder – developers, QA, Project & Product Management.

What we came up with were:

MUST HAVES
—————————-

  • Ability to merge bugs or bind them as related
  • Separate but integrated with Trello (or whatever sprint task mgmt/estimation tool)
  • Can upload screenshots easily and attach files
  • Can tag/label bugs and assign, prioritizeable
  • Logs and bug archive with timestamps, filterable, shows who closed and when
  • Opt in notifications per status (ex/ I am notified when new or pushed back)
  • Can comment on specific activity items (not just one long stream of comments not tied to anything)
  • Analytics (how fast are they piling up? how fast are they being closed? how has this changed over sprint cycles?)

 

NICE TO HAVES
—————————-

  • Can tie source code or specific commit to a bug that it fixes
  • Ability to write in markdown format (have you ever tried copy/pasting code into trello? don’t.)
  • Can close or change bug status from command line (ideally from a specific pull request)
  • Notification system ideally through growl, an app, browser extension, or something which isn’t email

 

 

Weighing alternatives
—————————–
Decision and Roll-out
——————————