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.
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.
I wanted to track a number of attributes for each piece of work:
We set up a “Dev Tasks” board with three lists:
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:
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.
The process works because of the following assumptions:
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.
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.