Welcome to part 3 of my Trello series! If you are new to Trello or curious how I set up my Trello boards for managing software projects, I encourage you to start at part 1. Here’s a quick recap:
- Lists represent a task’s position in my workflow: This Week, In Progress, Ready for Review, etc.
- Labels, on the other hand, measure a task’s difficulty: green, yellow, and orange refer to easy, medium, and difficult.
That’s great for simple tasks that can be entirely represented by a bit of text on a single card. But what about more complex tasks or interdependent tasks? I have a solution for that, too. Read on!
Generally speaking, Trello boards are flat lists of cards, so there is not much hierarchy. For many projects, that will be fine. As a rule, I try to keep my tools as simple as possible for as long as I can. More complexity means more time managing the project and less time actually designing or coding; at its worst, complex tools and processes can lead to bikeshedding.
However, I do find that a little more structure is good, especially on larger development projects. For those projects I use “themes” and checklists extensively.
I call a larger grouping of tasks a “theme”. Sometimes a large feature will require multiple cards to complete. I’ll group these by prefixing each card with the name of the theme.
Grouping cards this way is a bit tedious, but I think that friction is good. In general, I prefer to run a software project iteratively, by quickly adding many small enhancements and changes, rather than sporadically releasing “big bang” features. Trello’s limitations helps nudge me towards a more nimble style of development.
For tasks that need to be broken down into smaller steps, Trello does have an elegant solution: checklists. I use checklists all the time, even for small tasks, because Trello makes them so easy to create.
Checklists are great for:
- Documenting acceptance criteria – check them off once the tests pass
- Planning out implementation steps – if I get interrupted or I reach the end of the work day, the list helps me quickly pick up later right where I left off
- Reminders for important but easily-forgotten subtasks – e.g. did I remember to update the documentation?
Using checklists means I can keep the Trello cards themselves at a high level that my clients are comfortable with; checklists hide some of the messier technical details on the “back” of each card.
After reading this (or perhaps you’ve tried a similar system), you might wonder:
How do I decide what should be a checklist item versus its own card? Do I represent a feature as multiple cards with a common theme, or as a single card with a checklist?
Trello’s flexibility and lack of hard-coded structure means that there isn’t one right answer. Here’s my rule of thumb: every card should be achievable in one day or less. If a card represents a feature or task that will take more than a day to complete, I break it down into smaller cards.
Nothing’s worse than seeing a card stuck in the In Progress list for days or weeks on end. If this happens, its a sign that communication has broken down. By splitting big cards into smaller ones, I make sure that progress can be measured and my projects never seem stuck. Everyone likes to see the project moving forward!
Speaking of communication, that’s a topic I’d like to cover in more detail. Understanding Trello’s notification system can be a bit tricky, and I will try to unpack that a bit in my next post.
As always, if you have questions about my Trello process or have some Trello experiences of your own to share, feel free to shoot me an email. Thanks for reading!