Optimizing Trello for the 10-person Opbeat team

Trello is an amazingly flexible project management tool, and we have adapted it to our workflows since when we were just two founders who needed a little more structure, to a 10-person team today, consisting of multiple designers and engineers.


Before moving into a description of how Trello works, and how we use it, it might be helpful to understand how we move from getting a great idea to shipping a feature in Opbeat.

Everything is validated

Feature ideas come from many places—user feedback, research, or inspiration from other tools. In Opbeat, no feature moves to Production without having been validated as valuable, usable and feasible—it needs to deliver clear value to the user, they should instantly understand how to use it, and, of course, it needs to be technically possible.

Our validation process is quite straightforward:

  • Our Product Manager is responsible for gathering feedback on our current features, as well as validating any new features we are exploring.
  • The Product Designer is responsible for getting ideas mocked up and ready for validation. After a feature is validated, he is responsible for getting them ready for development.
  • The CTO is keeping a close look on the balance between new features, issues that arise, and performing the necessary operations, so everything is done in time.

To ensure that everything is on track in the everyday work as well, we have a daily stand-up at 9:15. The daily stand-up is where we talk about what each of us worked on yesterday, what we expect to work on today, and if there is anything that blocks that work.

Because Trello is so flexible, we have found that it is easy to adapt to our daily, weekly and monthly workflows, from idea, through validation and development, to ultimately shipping a better product for our users.

Our Trello setup

If you are unfamiliar with how Trello works, it is organized quite simply: In your organization, you have boards with lists on them. On those lists are cards. Each card has a title, description, members (assignees), label, checklist, due date, and attachments.

These are our four boards:

  1. Current Development
  2. Planning
  3. Issues
  4. Backlog

And this is how cards move between the boards:

1. Current Development

This is the board we primarily use, and these lists help us move things along:

  1. In design
    Validated features start here.
  2. Ready for implementation (Prioritized)
    This is the prioritized list of what the developers should work on next. Features that do not typically require any design go here directly (issues, refactoring etc.).
  3. In development
    All the stuff that is currently under development.
  4. Testing (/Staged)
    When development is done, the card moves here for testing.
  5. Ready for shipment
    After testing, the card goes here, if not directly to Live.
  6. Live (Week #)
    Every week we have a new list of cards that went live, and when the week is over, the list is archived.

It is important to note that not all cards go all the way from In design to Live. If a card is ready to be implemented, it goes directly to Ready for implementation—it might be properly spec’d out in the mockup stage already, or it is an issue that needs to be fixed next. A lot of what is developed is also designed directly in code.

In general, everyone brings great feedback to the table throughout the development process, so cards can move back and forth between In development and Testing—even Ready for implementation—a few times before being shipped. It is more important for us that the card is placed correctly, than being staunch about only moving from left to right.

2. Planning

Every Thursday, the Product Manager, Product Designer and CTO have a Product Meeting, where they discuss the feedback we have gathered from users, what other types of research tell us, and how old product ideas we had at some point might be useful now.

These lists help us follow cards through that flow:

  1. Potential Experiments
    All of our great new ideas for features start here.
  2. Ongoing Experiment
    The Product Manager validates (or invalidates) the features on cards in this with a select group of users.
  3. Next up (Validated, Prioritized)
    If a feature gets validated, it is in this list until a designer is ready to move it to In design on Current Development.

3. Issues

Even though we all want to make perfect software, the reality is that issues occur and bugs arise. For this board, we only have two lists:

  1. Inbox
    All new issues start here.
  2. Confirmed (Prioritized)
    When the issue has been verified by another engineer, the card is here, ready to be moved to Current Development.

This board is actually the only place we use labels on cards:

No label = Non-critical.
Yellow = You should look at this when you can.
Orange = Look at this after you have finished your current card.
Red = Work on a fix right now.

4. Backlog

During the Thursday meeting between the Product Manager, Product Designer and CTO, we do not just talk about upcoming features, but what is in the Backlog as well.

We love to ship new features that delight our users and make their work easier. However, sometimes, we need to take a step back and refactor or optimize existing code, so during the Thursday meeting, the CTO will bring up non-feature cards that needs attention during the coming week, to make sure it all runs as smooth as possible.

The lists here are:

  1. Frontend
  2. Backend
  3. Operations

The “Responsible” cards on these lists are another example of how Trello can be tailored to fit our needs. By having that card “stick” to the top, everyone knows who is responsible for each of the lists and for bringing up pressing issues.

Cards

Cards can be made to fit the exact flow you want. Here’s an example of a feature we are working on right now: A redesigned Error List:

You can quickly see who is working on it, and responsible for making sure it moves along.

The description is always focused around a problem we are trying to solve with this feature, so everyone on the team will always know why we are working on a particular feature. In the description, we also keep links to .PSDs and the corresponding branch on GitHub.

As written previously, we do not use labels for anything else than issues, and we do not believe in formal deadlines, so we will not assign a due date to cards. We keep the features described on cards as small as possible, so they are shipped when they are done.

The checklists are split into three; Design, Frontend and Backend. The tasks for each are kept on the card for posterity’s sake, so it is always possible to look back and get an idea of what the other team members have worked on previously.

We are huge fans of the activities list at the bottom of every card. Reading through the list gives a great overview of the work that has been done, and when. Comments are an essential part of this work too, both to give a status on what is missing or blocking further progress, as well as asking questions to others on the team.

Downsides

  • We have found that things that should be prioritized highly have a tendency to resurface—sometimes, unfortunately, in the form of duplicate cards. It takes work to be on top of the activity happening across boards and, occasionally, very long lists.
  • The Backlog has a tendency to be the place where cards go to die. Sometimes due to a duplicate card “skipping in line” and going straight to Planning/Current Development, or because of time constraints.
  • In general, it can be difficult to balance the priorities of operations cards with feature cards. It is the classic tradeoff between premature optimization and the systems being fast enough.

Tips

  • When you are assigned to a card as a member, you will get notifications about changes and updates on that card. If you are not a member, you can subscribe to it as well, which is immensely useful.
  • You can see the cards you are a member of via the menu in the right hand side, or via the shortcut Q.
  • If you want to see all the cards you are a member of across boards, go to http://trello.com/me/cards. It is really useful for developers looking at both new features, and upcoming issues.
  • Moving cards between lists is super easy for everyone, but having an overview of what should be moved between boards, and when, should preferably be delegated to a group that is responsible for keeping Trello up to date. In our case, we have found that it works with having a Product Meeting on Thursday where we try to keep a more general view of what is on the Trello boards.
  • Labels do not fit our flow, but tags would. It would be much easier for us to cross-reference which cards belong together for one reason or other.
  • Shortcuts are great and will make you fly through the interface. Learn a couple of them to begin with, e.g. S for subscribe, J/K to go back/forward between cards, Space to assign yourself to a card and A to assign someone else.
  • Try to keep as much conversation about features and issues as possible on the relevant cards. Today, you have a ton of places where you can get a hold of a team mate. We discuss designs on Redpen, have a general product chat on Slack, talk about errors and releases on Opbeat and verify Pull Requests on GitHub. That is a lot of disparate conversations, so try to reference them as much as possible on the Trello cards for the features you discuss. It is surprisingly handy to go back to an old card and find the links to the right discussions. (Redpen, Opbeat and GitHub all have permalinks that are easy to include.)