Change board structures often
I used to spend a lot of time up-front trying to design the perfect board structure but no matter what I’d end up changing it half-way through the project. Now I just start with something approximate and think of the board structure as something fluid that evolves with the project.
Because as a project moves through different stages it often makes sense to arrange the work differently—maybe to improve the flow of tasks from one step to the next, to create a better visualization of current state, or to emphasize changing priorities.
With a development project, for example, in the early stages you might want to have lists based around separation of technological concerns. At a later point it might make sense to group work around parts of an application. At another point structuring lists based on interactions with other teams might help. And leading up to a launch you might want to focus the flow on iterations or launch blocking items.
Throw away boards and start over
Sometimes you may discover that your board structure is totally wrong or that a certain phase of work has reached a completion point, such that the current board is creating too much friction. In these cases I now just abandon the board and start over with a clean slate.
The point isn’t to discard boards for the sake of it, but just that you should feel free to toss them when they stop working for you.
Use different boards for different teams
One Board to Rule Them All is an attractive idea and sometimes it makes sense, but in most cases different functions and different teams have different needs. Instead of forcing everyone into a generalized workflow I find it’s better to have separate boards so that teams can optimize their workflow for their particular needs (this is the Kanban principle of the “permission to be different”.)
Of course this comes with a trade-off: the downside to separate boards is that work can become siloed and you may lose a unified view of the project. The solution depends on the size of the project but it could include having a separate master board that tracks the salient activity in sub-boards, or just having someone who can span the boards and coordinate whatever needs coordinating between them.
Use work-in-progress limits
If you’re managing a team and using Trello in a Kanban-like way, make sure to set work-in-progress (WIP) limits on the lists. Nothing will do more to improve flow and productivity than limiting work-in-progress.
The benefits of WIP limits are beyond the scope of the post but it’s worth noting that limiting work-in-progress is a requirement for true pull systems (vs push systems): the pressure of the limit followed by the release is what creates the pull force that pulls work across the board.
Trello doesn’t provide a way to limit the number of cards that can appear in a list so I just add the limit number to the list title, for example: “Ready for Design (max=6)”.
Integrate with Slack
For me, the weakest part of Trello is the notifications and staying in sync with the board. If you’re using a lot of boards it’s hard to keep up with everything that’s happening. Missing an important update because someone forgot to include your username in a comment is a common issue.
Integrating with Slack solves the problem. Pushing Trello notifications into Slack makes all the board activity—creating cards, moving cards, commenting—visible to everyone on the team. And if you’re using multiple Trello boards with multiple teams, having notifications assigned to separate Slack accounts or channels helps keep things manageable.
The only challenge with the Slack integration is that you can end up with fragmented comment streams if some comments happen on the Trello card and some happen in the Slack channel. It depends on the type of work you’re doing but I find it’s best to keep as much of the discussion as possible on the Trello card so the conversation history stays attached to the work item.
For more stuff like this, follow me on Twitter.