Some say it’s so easy and versatile that there’s no wrong way of using Trello. From my experience using it in agile software development, I beg to differ: there is.
This post is not about advocating the use of Trello over any other tool: it has its strong points, and its limitations: I’ll assume Trello works for you, and that you’re already using it in some way (as the main tool, or as a complement to another tool).
I’ll focus on agile software delivery as a backdrop, but this is valid if you use Trello for other collaborative process — recruiting, onboarding, etc. If you think you might need metrics, statistics, history, etc., from your process, then what follows is stuff you want to get right from day 1. If you find out later that you needed them, you can’t get them back.
So, what’s the wrong way to use Trello I was talking about? It’s too easy to use labels for everything you can think of: they’re colored, they appear on the face of your cards, so it’s temping to use them as the go-to construct to convey any metadata on your cards. But…
…labels suck at conveying card state
It’s tempting to use a “yellow“ for “needs validation”, and then “green” for “validated”, but that is plain wrong.
Notifications: If someone adds/removes a label from a card, no-one hears about it (does it make a sound?). People subscribed to the card… don’t get a notification! Why else would you subscribe to the card? Also, the board doesn’t get an activity indicator. So, if your labels represent state, you lose visibility of the most important thing in a collaborative process: state change.
History: There’s no accessible record of when labels change, neither the path through these changes. If you’re trying to get any metrics from a board (burndown, lead time, etc.), or identify bottlenecks in your process… you don’t.
Accountability: You don’t know who changed a label. Depending on how you use card members in your process (beyond this article), you can infer this from people joining/leaving the card (but you don’t know when labels changed, so the truth in this may vary). If you’re into self-organizing teams, and shared responsibility, then this probably smells like witch-hunting and blame-game to you. However, it doesn’t need to be so. If your team is trustworthy, this kind of transparency can still be very useful—because you can always know who to turn to when seeking help or info on something that was done. Furthermore, your Trello-based process may include external parties with which liability and litigation are potential issues—and this “paper trail” may come in handy to mitigate potential conflicts.
For card state, use lists
This is already how you can describe the basic layout of To Do — Doing — Done, so no news here — this is a safe bet as a starting point. The key here is reflecting your process. If, between being slated “to do” and being considered “done”, most of your stories/features/task pass through many steps, then you should break the Doing list into lists reflecting those steps. You can see this kind of breakdown in Daniel Zacarias’s example Kanban board (part of his multiboard Trello setup for dealing with a large product backlog).
I can’t stress this enough: you should first understand your process (which in turn implies you have understood how the people/roles involved interact), and then translate it into your tool in the best way possible.
The way I’ve seen labels infect this is by having the various stages of “doing” represented by labels. Not only does this suffer from the shortcomings of labels we’ve seen above, it does not reflect the real process. The various stages of “doing” are in line with the process’s flow from “to do” to “done”, whereas, by using labels, they’re being represented as orthogonal to this flow.
Aside: you can also break your “To Do” state into multiple lists (e.g. Product Backlog vs Sprint Backlog).
For finer-grained/specific state, use checklists
There are, at least, two cases of process state where using a list is not the best. The first one is progress — you wouldn’t have a developer pass a story through lists like Doing (20%), Doing (40%), Doing (60%), etc. The other one is what you could call “exceptional state” — and this why I specifically wrote “most of your stories/features/task pass through many steps” above.
If a sequence of steps is specific to a card, or to a few cards (or a specific type of card), creating lists for those steps will only create visual noise most of the time—a list that’s empty most of the time. Cards representing the task to deploy a new release to the QA or production environments are a good example.
For both of these you should use checklists. Checklists even keep the good things labels lack: notifications, history, and accountability.
Use labels for stuff that does not change (much)
The above three aspects where labels fall short are linked to the notion of change. So let’s keep “labels” and “change” as far away from each other as possible, and (repeat after me):
Here are some examples of how you can apply this motto.
Labels for types of card
Focusing on software development processes for now: a feature doesn’t change into a bug (or vice versa) that often (and, for the few times it happens, it’s not that critical to know the “when” or “who” of that).
This also true if you’re using Trello for different kinds of process. For recruiting, you can use labels to signpost what role a person applied to. With the right setup and tools, you can identify interesting bottlenecks in your process, such as which roles take longer from application to hiring/rejection, or where are the bottlenecks in your recruitment process.
Labels for themes, epics, product areas/components
This is particularly interesting for boards dealing with processes upstream from software development: product management, planning, roadmapping. In the aforementioned multiboard Trello setup from Daniel Zacarias, this roadmap example board:
shows just that. You can also use labels for the KPIs each feature is aiming to improve—acquisition, activation, retention, referral, revenue, etc.
Labels for priority, criticality, impact
I’m not a big fan of using labels for pure “this before that” priority — that should already be implied in the order of the cards, but labels can be used to convey information that helps prioritizing cards. This is consistent with the “labels for stuff that does not change (much)” motto.
In particular, labels are great if you need to highlight a different notion of priority — which I prefer to call “criticality” or “impact”. Justin Cone proposes doing it with a set of 4 labels that express how a certain card affects the product being developed (Blocker, Annoying, Cosmetic, Reference). Other examples are JIRA’s default priority levels:
Mix and match
If you use only one of the three examples provided above, you end up not taking advantage of the fact a card can have multiple labels. That’s not bad —you don’t need to use every Trello feature — but there are some interesting ways you can combine these approaches.
Type + (some) criticality: my preferred setup for small projects fits this description. On the card type aspect, there are labels for Features, Chores (or Tasks), Bugs, and Epics. On the criticality aspect, I use only a label to say “something” is Critical — it can be a critical chore, a critical bug, etc.
I admit two details come from to pet peeves of mine about prioritization:
- the red label is deliberately called Critical instead of Urgent (and I’m adamantly against having an Urgent label); and
- the Bug label is deliberately not red (because when you have a large backlog, you need to prioritize aggressively, and this includes acknowledging that not all bugs are urgent/critical).
Type + theme: in the example above, the Epic label means “this card is an epic”, but you can instead use multiple Epic labels to mean “this card belongs to epic X”. These “Epic X” labels are mutually exclusive, but can go together in the same card with a “Feature”/“Bug”/“Chore” label. You can see this approach in action in this Corrello screenshot (blatantly lifted from their newsletter).
This way you can quickly identify how close you’re to complete a given theme, or to have delivered all the features you have identified as improving a given KPI for your product.
What’s in it for me?
Besides dealing with the drawbacks of labels w.r.t. notifications, history, and accountability, all this advice allows you to support an activity that’s crucial to agile methodologies in particular and empirical processes in general: Inspect & Adapt. Trello doesn’t give much insights on your boards on its own, but you can achieve that with third-party tools. Corrello, for instance, is a paid tool that will chew on your boards and give you dashboards with:
- the backlog overview I’ve shown above;
- a cumulative flow diagram, allowing you to gain insight into cycle time, likely completion dates, and process bottlenecks;
- cycle time charts and tables, especially useful in setups with multiple “Doing” steps, allowing you to focus your attention to the steps which appear to be your bottlenecks.
Don’t follow the siren song to use cute, colored labels for everything. Friends don’t let friends add a green “Done” label to a card. The main stages in your pipeline are better represented as lists. More fine-grained or sporadic states are nicely handled with checklists.
Use labels for stuff that doesn’t change (much). This can be a card’s type (feature, bug, etc.), theme/epic/KPI, criticality, or a mix among these.
References, inspirations and recommended readings
- Scrum with Trello, and How To Manage Scrum And Kanban Teams In Trello With The Corrello Power-Up, by Corrello’s Robin Warren;
- Justin Cone’s 4 tips for working with Trello;
- Organizing a large product backlog on Daniel Zacarias’s Folding Burritos product management weblog — along with the companion Trello template with some great inspiration boards.
Disclaimer: I’m not affiliated with Trello or any other entity or brand mentioned in this post. Furtermore, this post represents my personal opinion on this subject, not that of any company I work (or have worked) at/for on this subject area.