Some say Trello is so easy and versatile that there’s no wrong way of using it. From my experience using it in agile software development (from simple projects to long-lived products with multiple epics), I beg to differ: there is. Let’s talk about some Trello best practices.
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 you’ll want to get these Trello best practices right from day one. 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…
…Trello’s 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-organising teams and shared responsibility, 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.
So, if state and state changes are so important, what is the right Trello feature to express them?
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 most of your stories/features/task pass through many steps between “to do” and “done”, 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 labels represent the various stages of “doing”. 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, you’re representing them 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.
So what are labels good for?
Use labels for stuff that does not change (much)
The above three aspects where labels fall short relate to the notion of change. So let’s keep “labels” and “change” as far away from each other as possible, and (repeat after me):
Use labels for stuff that does not change (much)
Here are some examples of how you can apply this Trello best practice.
Labels for types of card
Let’s focus on software development processes for now. A feature doesn’t change into a bug (or vice versa) that often. 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. Which roles take longer from application to hiring/rejection? Where are the bottlenecks in your recruitment process?
Labels for themes, epics, product areas/components
Labelling the card according to their epic is particularly interesting for boards dealing with product management processes upstream from software development. 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 ( the order of the cards should already imply that), but labels can be used to convey information that helps prioritising 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 (Blocker, Annoying, Cosmetic, Reference). Other examples are JIRA’s default priority levels:
or Matt Rizzo’s High/Medium/Low priorities.
Mix and match
If you use only one of these three examples, you end up not taking advantage that 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. As for criticality, I use only a label to say “something” is Critical (critical chore, critical bug, etc.).
I admit two details come from to pet peeves of mine about prioritisation.
- I deliberately call the red label Critical instead of Urgent (and I’m adamantly against having an Urgent label).
- The Bug label is deliberately not red. When you have a large backlog, you need to prioritise aggressively, and this includes acknowledging that not all bugs are urgent/critical.
Type + epic: in the example above, the Epic label means “this card is an epic”. 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 are to
- complete a given theme, or
- have delivered all the features you have identified as improving a given KPI for your product.
Why should I follow these Trello best practices?
Besides dealing with the drawbacks of labels (regading notifications, history, and accountability), all this advice allows you to support Inspect & Adapt. Inspect & Adapt is crucial to agile methodologies in particular and empirical processes in general. 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 for Trello, 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.
Summary of Trello best practices
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 brand mentioned in this post.
- 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.