I just posted an article over on InfoQ showing everything I’ve learned about how teams are using Trello to run their Scrum (and Kanban) processes. I learned this from talking to over 100 teams using Trello for their Scrum and Kanban process while building Corrello over the last 12 months. I thought I’d post the other side of the article here, the things I’ve seen teams doing which can make their experience a pain in the arse!

Because Trello is so flexible it’s possible to run your process however you want. This leaves people with the ‘blank page’ problem when trying to set up their boards, and no doubt a whole load of other things they’d rather be doing instead. Most of the time people seem to settle on a pretty consistent set of conventions. These are some of the other things I’ve seen teams doing. If you’re doing one of these, possibly it’s a great fit for you and your team and you should continue as you are. Or, maybe it’s time to reconsider how you’re using Trello for your Scrum process.

1. Creating a new board for each sprint

I’m not sure where this convention comes from. Maybe there’s an article out there I’ve not seen which promotes this practice but this seems to be the most consistent way people confuse themselves. The cons here are

You need to create a new board for each sprint. Obvious, and not a great pain but still it’s more work than not creating a board.

You need to move cards onto each new board at the start of the sprint.

You need to archive old boards or drown in a sea of old pointless sprint boards.

Really, this is going to become a pain at some point. The only benefit I can see is that it gives you a record of what work you got done in each sprint. A better approach if you need that is to have a new ‘Done’ list for each sprint. The old lists can move off to the right of the board so they aren’t in your way but are there if you need them. You can then archive them once they aren’t important enough to have on hand all the time.

The basic board set up I recommend is something like this

Sprint backlog

In progress (may be multiple lists ie dev/code review/test)

Done

2. Going label loopy

This is less common but I think specific perhaps to people coming from using something like Jira. With this pattern people decide to create a label for every type of card so they can categorise everything. Is it a ‘task’, ‘code quality’, ‘technical debt’, ‘user story’, ‘epic’ etc. The problem is that in tools like Jira you actually choose what type of thing it is when you create it, can’t not select one and can’t select more than one. In Trello you can create something without a label or with multiple labels and need to remember to classify every new card. This falls down when you want to

Do something other than label cards all day long Go home at a sensible time rather than stay up adding labels all night

OK ok ok, so I may have indulged in a little hyperbole there but I think you get my point :). The labels I recommend people use are these

Bug: for bugs

for bugs Blocked: for blocked tasks, preferable to a blocked list as you can see where in the process it got blocked

for blocked tasks, preferable to a blocked list as you can see where in the process it got blocked Whatever you need for your Epics. Using labels for individual Epics seems to be the best approach for grouping those cards together.

Marker cards to group sub-tasks

This is really very rare, but still common enough to be worth mentioning. If you have a single list it can be a common practice to split the cards in the list up with ‘marker cards’. These usually have an image attached so they stand out as something different and act as headings to break up the list into sections.

Where this can work is if you have, for example, a board for upcoming speaking gigs (an actual example I saw) and have sections for ‘things to do while visiting town X’, contact details for organisers, flight/travel info etc. What this is really is a way of organising a bunch of notes in Trello.

Where this fails is when you have cards which move from one list to another (like in a Scrum process!) The most common way people use this is to group cards into Epics. Which probably works fine so long as they stay on the backlog list but as soon as people start working on the cards in the epic you start losing knowledge of which Epic a specific card was related to or need to maintain those headings in each list and if anyone moves a card to the wrong place, well good luck! As mentioned above the best approach to managing Epics seems to be to use labels. Update: There is now also an excellent Power-Up Hello Epics which helps with managing Epics in Trello.

That’s it, the three biggest mistakes I’ve seen teams making. That’s not to say you shouldn’t be doing these things if it really is what works best for you and your team. If you’d like to take a look at what I’ve seen as being the best practices check out the article on InfoQ. And if you’re on an agile team using Trello you should check out Corrello, the dashboard tool for agile teams using Trello which gives you burndown charts, cumulative flow diagrams, release burnups, cycle time and more.