Lessons learnt from using Trello to build the new amee.com

Since around late summer, and inspired somewhat by Richard White’s post about the same subject at Uservoice, we’ve been using Trello to help support our development process at amee.

In this post, I’ll explain for other teams using scrum how we use it, and the lessons we’ve learnt from nearly 8 months of heavy use.

TL:DR – the short version

amee uses multiple trello boards in unison to manage web development, and you can get the gist of how we do this by looking at the diagrams below. We use one main trello board to manage current development, which is fed by a series of supporting boards to keep things manageable.
It’s not perfect, but we like how easy it is to adapt in response to changes in the business.

The full version – how we use Trello

For those new to Trello is a powerful, but extremely open ended, free project management tool that uses the concept of Boards, Cards, and Columns, to represent work that needs to be done, and what stage a given piece of work is at a given point in time.

As a public display of eating their own dogfood, you can see Trello themselves use Trello to build Trello on their public board here.

Like a fair few other companies around Old Street, we’re applying a variant of scrum to manage the development process.

We run a weekly set of sprint reviews, retrospectives, standups and sprint planning sessions as is common with scrum, but we also use a series of Trello boards, to help support the process. It looks a bit like this:

What the boards are for

  • Current development – this represents work we’re doing right now, and where we are. the majority of the team’s time is spent here.
  • Bugs – when users or team members mention something that isn’t working, if copy isn’t clear, or some other defect is discovered, it’s raised here for review.
  • Ideas – new feature requests from support, or ideas inside the company are raised here.
  • Roadmap – this is the high level view, of the next few months, and with less definition, the company plans for the next few quarters.

Moving the cards

It helps to imagine the cards, representing ideas, user stories, or tasks flowing from each of the boards, and as they get closed to being built, they’re gradually better defined.

This looks different for each of the boards we use but in general, the theme is the same – things move from left to right as they’re refined, prototyped, and eventually built.

Developing in the sprint

Most of the team’s time is spent working from this board, and and over the last 8 months, it’s undergone the most change as we try different tweaks to our process.

This board exists track progress in a given week – at the beginning, we start with a load of cards bunched on the left around the To do column, and by the end of given sprint, assuming all went well, Done should be crammed full of cards.

What the columns mean 

  • Backlog – User stories for new features are fleshed out and refined here. We work on them, creating wireframes, or if necessary google docs, until they’re small enough to deliver in a sprint, and in a fit state for estimation. This would be referred to as the product backlog in scrum parlance
  • For review next sprint – Once they’re in good shape, we move the stories from the backlog into this column. The team look over these before a sprint planning meeting, so it’s possible to make an informed estimate when planning the next sprint.
  • Issues and bugs – Once we’ve investigated, we’ve accepted the bug, and know the fix for a bug raised on the bug board, we list them here for the team to pick up. When planning our sprint, we’ll adjust how many stories it’s wise to commit to, based on how many bugs we plan to tackle in a given sprint.
  • To do – These represent the stories picked for a given sprint. If you’re applying scrum elsewhere, you might think of this as the sprint backlog.
  • Doing – When a developer picks up a story from the “To Do” column, they’ll move it into here, and where possible, have a conversation with someone on the product team, about how best to meet the original intent.
  • Code review – Once a developer has written tests and developed a story, another developer on the team conducts a quick code review. We do this to spread knowledge in the team, but also to keep a consistent, readable codebase. The team will often pair program on features too – in this case, they push it straight to a staging server for testing, as code review has been continuous.
  • Testing / QA – Once a feature has passing tests, has been code reviewed, it should be in shape for someone on the product team to test it and sign off on it.
  • Done – The user story is done! Success!

 

How we deal with bugs

Of course not everything is plain sailing in development – we end up raising issues and bugs based on feedback from users via our support channels, when running user testing, or as we QA new features.

The aim of this board is to investigate them to the point that either:

  1. They’re accepted as a known issue, but not an immediate priority, OR
  2. They have a well defined fix, so they can be worked on in a future sprint. In this case, they’re shifted to the “bugs and issues” column on the current development board

Over time, we’ve found the following columns helpful:

  1. Reported bugs – This is where bugs are dropped initially – the aim is to keep this column empty, or as small as possible. To encourage nice, well described, reproducible bugs, we have a boilerplate bug card we use as a template.
  2. Being reviewed – we use this to represent bugs where someone has picked it up and needs more feedback to proceed on it.
  3. Accepted, but low priority – in some cases, after looking into a bug, we’ll work out the desired fix, but it won’t be a show stopper. In this case, we leave them here, for future sprints, or to pick up if the team finds itself with spare capacity at the end of a sprint.

Managing Ideas

Ideas and new feature requests bubble up in a similar fashion to bugs – they can come from anyone in the team, and from user’s feedback.

In general, the product team spend the most of time here, reviewing them until they’re in a shape to be accepted.

What the columns mean

  • New ideas – ideas can be added here by anyone inside the company.
  • Being reviewed – once someone in the product team has picked up the card and is looking it over, or talking to whoever’s idea came forward with it, it’s visible here.
  • Accepted – once a story is understood well enough, it’s added here. From here, it’ll make it to the backlog, to work out when it can be built.

Working from the roadmap

The final board that feeds into development is the product roadmap itself that bucks the “left to right” trend for showing progress.

The further out to the right the cards are on the board, the further out from the present day the features are, and lower the certainty there is about what the feature will look or act like.


As a rule, cards on the roadmap describe features at a very high level – various parts of the description are pulled out of them and split into smaller stories for the backlog, for further definition.

Lessons we’ve learnt along the way

Things we liked:

Surprisingly scrum compatible

One thing we’ve found is that trello can be quite simple to adapt for scrum. We’ve found it’s pretty straightforward to use the scrum for trello browser plugin to help to track how much we’re delivering from one week to another, and work out how many stories we can fit into a given 1 week sprint.

Clearly shows progress

Seeing cards move from left to right in a week gives a good idea of how a sprint is going a glance without relying on burndown charts.

Easy to change

While trello isn’t explicitly designed for software development, it’s lightweight and simple enough to try using it one way a week, then try using it another without too much effort. When we’ve had to deal with changes in how we can deploy, it’s been easy to adapt how we work to fit it.

Things we had to work around:

You can’t just treat it like more common issue tracking tools

If your team is used to using long pull requests to have conversations on github, or pasting code into comments like Jira et al, trello can be quite a shock – trello cards by design can’t show much information on them, and the comments don’t allow formatting of code snippets either.
This forces a fair amount of documentation either into the actual code, or tests, or elsewhere, like specs in google documents for example.

Analytics are extra

We rely on an external browser plugin to help estimation, and if you want analytics, you’ll have to fall back on the ecosystem to get the same kinds of charts and graphs you’d get by default with Greenhopper, or Pivotaltracker.

Tracking cards across boards can be a pain

When you’re working on a single board, you can happily refer to cards by their number, which makes tracking issues on the one board relatively simple.
However, because of Trello’s design, when you have separate boards, you can’t rely on card numbers to track cards across them, which is a nasty shock if you’re used to Github, Jira or Pivotal. As ever, there are workarounds, but it still can be a pain.

How has it been for you?

We know we’re not the only people using Trello to help build better webapps, and hopefully this has helped shed some light for other development and product teams.

If you’re using it yourself, or you have any questions about how we use it, let us know in the comments – we’re still working out a lot of wrinkles ourselves, but so far we’ve found Trello to quite a promising tool in our quest to build a better amee.com.

 

Back to AMEE Blog