I’ve been using Trello for a couple of years to track the work of a team of 4 software developers and one tester. This includes tracking features currently in development, future work, bugs, the progress of testing, and past releases. I think it works pretty well in this context and is a lightweight alternative to dedicated bug trackers and project management/planning software.

Why Trello

I believe in introducing process only when it is required to maintain or improve productivity (rather than eg just because “we have to have a bug tracking system”). Trello is sufficiently polished and flexible that tracking work in it doesn’t create much friction (but even Trello is buggy!). Tools have to create minimal friction, or they will be a source of frustration (or fall out of use altogether).

Trello allows uploading images to the cards, and commenting on them. Card can be labelled, searched and ordered. It can send out notifications by email or via Slack. It’s also possible to work with cards via email.

Trello integration with GitHub looks interesting but we used a different service for our source code so I didn’t get to try it out.

The process

I wanted to track a number of attributes for each piece of work:

• What component it’s in
• Is it a feature or a bug
• Who is assigned to work on it
• Does it affect other components (fairly obvious which ones in our case, and by flagging cards this way we could avoid creating one card per component for each feature)
• What state it’s in (details below)

We set up a “Dev Tasks” board with three lists:

• Future: to keep track of stuff that would possibly be developed in the future
• Current: work items in development
• Staging: work items in testing

Each release then got its own list containing cards that went into it. At the end of the year, releases for that year got moved to a separate archive board.

We used labels to keep track of the state of a work item either in development or in testing:

• Red: Bug
• Magenta: Affects other components
• Blue: Ready to review
• Light blue: Review completed
• Orange: Problems found in review or testing
• Yellow: Ready to test (after rectifying problems)
• Green: Ready to release

So a work item would have these possible states defined by a combination of its list and label:

Future -> Current -> Ready for review -> Review problems -> Review completed -> Deployed to staging & ready to test -> Testing problems -> Ready to test again -> Ready to release.

The component would be specified in the card name (eg “Mobile: Upgrade to new CSS theme”). The card name is supposed to be short, with details going into the description field.

We recorded some of the review and testing issues in the card comments, although a lot of the discussion would happen interactively via Skype or Slack.

Assumptions and limitations

The process works because of the following assumptions:

• Small team
• Short release cycle (3-6 weeks)
• Small number of components
• Small number of states a work item can be in

As a result, it’s easy for everyone to remember how to mark up the items, which lists and labels to use etc. The lists are manageable because of the short release cycles; the aim is to keep them to a dozen items or so.

Conclusion

Trello provides a low overhead way of tracking software development and testing work for a small team. I would use it again if I had to setup a process for tracking work in a similar context.