Using trello to manage product development flow

For the last 3.5 years, I've used Trello to manage product development projects. When used properly, I've found that Trello gives transparency into a development process and gives early warning of possible pitfalls.

But there are tricks to using Trello well. Though its concepts are simple, they can be applied in many ways, some more effective than others.

The big idea is to use Trello to organize detailed tasks in a way that makes sense at a glance. I've found this organizing process to be faster with Trello than with tools (e.g., JIRA and Asana).

Below, I'll cover some tips for how I've used Trello to manage projects.

Defining columns

The columns on a Trello board should represent the stages of your process. I've generally found it helpful to have a Backlog (or Next Up) column, an In Progress column, and a Built (or Done) column. Some processes also expose the need for other columns.

Tips

Don't let your columns get too big! Big columns indicate that too much is happening at once, and they are a leading indicator of delay, which is surprisingly expensive. Surfacing these sorts of traffic jams is the most important thing that Trello can do. Don't start new work if your columns get too big. Unblock stuck projects and get them done! See this series for more information.

Columns should represent your true process and not the process that you wish you had. If every feature gets tested manually, then you need a Needs Testing column. If that column explodes regularly, it's a good sign that you either need to staff up on QA or automate testing, or both.

Defining cards

Each card should express a customer-visible deliverable.

Tips

Cards should make sense to the whole team, including designers and managers. "Launch scheduling notifications" is a good card. "Add push_server to constants.py" is too detailed.

Split cards when their scope gets too big. Delivering some functionality sooner is usually more valuable than delivering a lot of functionality later. Splitting a big card into small cards focuses the team on delivering sooner.

Split vertically when possible. Splitting "launch scheduling notifications" into "API work for scheduling notifications", "web work for scheduling notifications", and "notification pipeline work for scheduling notifications" is a horizontal split of work. Finishing one of those cards doesn't allow you to ship anything sooner. "Launch scheduling notifications by email" and "Launch scheduling notifications by SMS" is a vertical split. Each of those sub-cards can deliver something valuable to customers.

Allow multiple people to work on cards.
The team's focus should be on delivering results and not on "getting my work done." When multiple people work on a card, it's likely that team members are working together to deliver something.

Checklists

Checklists capture low-level tasks. I encourage people to track everything that needs to be done on a checklist. The audience for a checklist is the author and collaborators. People who aren't actually doing the work don't need to understand each checklist item.

Tips

Individuals should track their tasks. It's so easy to add, edit, and complete tasks that individuals should always keep them up to date. Managers shouldn't need to maintain checklists for a team.

Look at the trend in the number of incomplete tasks. This trend gives you a good sense of when you'll ship. Initially, most projects start with a small number of tasks — say 5 tasks, of which 0 are finished (5 incomplete tasks). As work begins, the team quickly discovers new tasks and adds them to the checklist. Perhaps that list of 5 balloons to 20 items, of which only 2 are finished (18 incomplete tasks). When the number of incomplete tasks is increasing, the team is still understanding the problem and you aren't close to shipping. When that number is decreasing, the team is polishing and getting close to finishing.

In summary

Columns represent the structure of your workflow. When they get big, they predict delay. So don't let them get big!

Cards should be understandable to the whole team, including managers.

Keep cards small and "vertical".

Multiple people can (and often should) work on a single card.

Checklists tell you a lot about when a project will be done, if you keep them up to date.