
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
Projects
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:
- Create a new Current Sprint board each cycle and archive the one that just passed
- 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.
Conclusion
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:
The only problem I’ve found with Trello is that moving cards between boards assigns a different ID number which makes tracking difficult. This makes using multiple boards a non-starter.