Product Management with Trello

Product Management with Trello

Here at AREA 17 we like to track project scope with User Stories. I completed Scrum Master Certification a few years ago and have been trying to find a suitable alternative to a physical project board ever since. In my opinion there isn’t any better way to track a project’s progress than using physical story cards pinned to a board. Having a visible representation of project status for everyone to see works incredibly well.

At AREA 17 almost all of our projects have a distributed team — often in very distant locations (New York, Paris, Argentina, London, Manchester). This makes sharing project status using a physical device almost impossible.

We’ve tried lots of ways to solve the problem. Here are a few:

  • Reliance on email — mostly disastrous
  • Task management apps — better, but not great
  • Issue tracking apps — better still, but often quite ugly and lacking a visual way of representing workflows
  • Pivotal tracker — the best up to now, but in my opinion it’s become overly complex and not a particularly nice thing to use from a UX perspective

Enter Trello

Trello was first released in 2011 at a Techcrunch event by Fog Creek Software. At the time I didn’t pay a whole lot of attention. It felt a little too simplistic and lacked a few features that I thought I needed (turns out I didn’t). Since then I’ve used it to manage several side-projects and more recently, projects at AREA 17.

For mapping a product roadmap, and tracking design/build progress it does just about everything I could ask for. Instead of forcing a particular structure or workflow, it provides a few simple structures and constructs:

  • Organizations — an organization contains a collection of boards
  • Boards — a board contains a collection of lists
  • Lists — a list contains a collection of cards.
  • Cards — represents an individual ‘thing’ be it a feature, a task, a bug, or whatever you decide it’s best used for. They support multiple checklists, commenting, and file attachments. Really useful for tracking feature discussions

Cards can be assigned to lists and any user can subscribe to a card, a list, or an entire board.

Trello in Practice


Organizations are a great way to represent a project. It’s often preferable to run multiple boards inside a project. Grouping these inside an organization keeps things simple and avoids the need to prefix board names with a project title.

Product Backlog

A product backlog typically represents a log of all features currently up for consideration. In Trello I like to create a Backlog board and  break it down into the following lists:

  • Ideas — new stuff ready for discussion and prioritization
  • Gathering Requirements — features that have graduated from an idea to something we all agree should be considered part of the product at some point. At this stage requirements are discussed and added to each card in the form of user story checklists
  • Ready to Estimate — features that have been defined enough for estimation to take place
  • Sprint Candidates — features that are ready to be assigned to an upcoming release

It’s worth noting that the order in which each card appears in the list usually defines priority. We always pick from the top of the list.

Current Sprint

We work in release cycles of varying length from a week to a month. Regardless of the duration, I like to create a Current Sprint board and break it down into the following lists:

  • Sprint Backlog — This lists everything we expect to complete within the release
  • Doing — Each team member moves a card from the Sprint Backlog into Doing when they start work on the feature
  • Ready for QA — Cards are moved here when the team believe it’s complete and ready for testing
  • Done — Cards are moved here when all QA has passed

We’ve found two ways to manage the Current Sprint board as a project progresses:

  1. Create a new Current Sprint board each cycle and archive the one that just passed
  2. Re-use the Current Sprint board and create new Sprint Backlog and Done lists with date stamped titles when a new cycle arrives. The old lists are archived for future reference

For shorter projects I prefer method 2.


In my opinion the flexibility and lack of pre-determined organizing principles are the key benefits of Trello. You can really organize your project in whatever works best for your team.

There are a few nuances of managing a product using Trello that I haven’t covered here — but I plan to do so in future posts:

  • User assignment
  • Labeling
  • Scheduling
  • Estimation

You can sign up for a free Trello account here: