Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Scrum with Trello

Scrum with Trello

Trello recently passed the 10M user mark and is fast becoming a popular tool for Agile teams of all flavours. Its simplicity and the great web and mobile experience seem to win some teams over versus other more complex solutions out there. It is also pretty un-opinionated on how you use it, which can lead to some confusion as to how best to implement a Scrum process in Trello. I've been talking to a lot of people over the last year about how they're using Trello for their Scrum and Kanban processes, as well as reading everything I could on the internet relating to running Agile processes in Trello. So, today I present to you with the fruits of that labour: Everything I know about running a Scrum process in Trello.

Let's get started...

The basics

Setting up your board

Let's get started with the real real basics (don't worry it gets more interesting soon). Let's get our board set up for Scrum. This is what a basic board would look like, I'll suggest a few additions to this throughout the post.

Your process may vary from this but the key lists here are

  1. Sprint backlog: plan your work in here at the start of the sprint
  2. One or more 'In progress' lists in the order they occur in your process. I've got Dev, Code review and Test.
  3. Done: Cards are put in here as you complete them throughout the sprint.

Apart from the variations in people's 'in progress' process I've seen a few other tweaks. Most notably, some people call their ‘done’ list after the current sprint (ie ‘Done 29th Feb 16’) and once the sprint is finished create a new list for the next sprint. This way you have an archive moving off to the right of your board showing what got done in the last few sprints. When it's appropriate you can decide the older sprints aren't relevant and archive them. This is a nice way to keep track of what got done in recent sprints, something which always seems impossible to remember when you need to :).

The other big difference is where you keep your future sprints and the rest of your backlog, which is why I didn't include lists for that above. I'll cover that below in the release management section.

One other useful addition is to add a ‘Ready for’ list ahead of each of your ‘in progress’ lists. This can make it easier to see why work is building up. Lots of cards stuck in test? Now you can see if they are ‘Waiting for test’ or ‘In test’, each could have different causes and quite different solutions. This is especially useful when combined with a Cumulative Flow Diagram (see useful plugins below).

The cards

There are some niceties when it comes to setting up your user stories on cards in Trello. Firstly, you can use markdown in your description, letting you easily create nicely formatted descriptions of what you want (details here). Secondly, you can add whatever documents you want, including linking to documents in Google Drive, Dropbox, Box or One Drive.

Finally, if you want to, you can attach an image to the card which will also appear on it in the list. This can be a good way to make things a little more visual and allow people to more easily find the card they're looking for on busier boards. This is probably best for larger tasks on a backlog which your stakeholders are looking at rather than on your primary Scrum board.

The slightly less basics

Using Labels without going insane

So, you've got your board set up and you're starting to add some cards for an upcoming sprint. Some people's next instinct is that they should be using more labels. Labels are good right? So let's create a nice taxonomy of everything we could add (User story, Task, Bug, Epic, etc.) and use labels to classify each card!

Erm... Not so fast. My recommendation is to start off with just one label, for bugs. Make it red, which stands out better than other colours for humans scanning the board. Having labels for things like 'tasks' or 'story' etc. can mean you end up spending your life categorising your cards, rather than getting actual work done. If you think you really need something more comprehensive, try to have a 'default category' (probably User story) which doesn't require a label and apply labels to the other cards. This saves the effort of adding those labels at least, without harming scanability of your board.

Two other labels which you may want to add are "Blocked" and "Urgent".

The "Blocked" label is for tasks which are currently blocked by something outside the team's control. Some people use a separate list for this. However, using a label rather than a separate list means you can see which part of the process the blocked items are in. This also allows you to see if they are contributing to a build up of work at one part of the process.

The "Urgent" label is often not required as these tasks can usually be flagged up at the daily scrum. However, if you want some special handling of urgent/expedited tasks, even just to make it easier to spot these tasks on the board, using a label is my preferred approach.

Top tip: To quickly add a label to a card you can put your mouse over it and hit the number relating to that label. You can also use the number keys shortcut when you've got a card open, so long as you're not editing the description or anything.

Life without child tasks

Finally, work begins! As the team pulls a story into the sprint they will likely want to split it up into its constituent tasks. This is where you get sad because you don't have child tasks in Trello, but it's really not a problem.

There are a variety of ways you could solve this, I'll cover some of the alternatives and their downsides below. For now, just know this. Use checklists. It's simple and it works. Each subtask can become an item in a checklist on the card. As you check off the items you can get a nice count up towards the work being completed. And if you have work which can be split up into bigger chunks you can actually put it in multiple check lists. OK, so this means the whole card moves across your board as one, so no testing early deliverables. This is where you need to use some common sense and to sometimes split the card up into multiple cards, and other times to add checklists. Where something is deliverable as a standalone unit, create a separate card. Where it's just part of the work of getting that card done, add it to a check list.

In this screenshot we can see how we’ve used markdown to bold some of the checklist items and then indent others to create another level of the parent-child relationship. This can be an extremely effective and simple way to keep your checklists tidy.

Two other options I've seen are people using some coding in the card titles to group them together, or using a spacer card between tasks as a sort of floating swim lane marker.

The first option can kind of work, you add something like [US-CFD] to each related card to identify them as part of the CFD User story. Part of the problem here is keeping on top of adding the relevant bit to every card. The other is that there is still nothing actually tying the cards together so they can easily get spread out from each other.

The spacer cards option starts off looking a bit messy and gets worse from there in my experience. On top of that, it's all too easy to drop a card in the wrong place and confuse everyone.

Both of these solutions are really trying to do something which Trello is not really built for. Stick to what it does well (ie checklists), and you'll be a lot happier.

Life without Epics

The other main use of a parent-child relationship in Scrum is for tracking Epics and the stories which make them up. There are a couple of solutions here. The most popular and successful I’ve seen is to use labels. These move with the card between boards and make it pretty easy to see how much of an Epic is completed vs still to be done.

The other alternative is to have a list for each of your upcoming Epics or features. The problem here is you lose the relationship with the Epic once the card moves to another list. Depending on your process this may be more or less of an issue. Using labels seems to be the most popular solution and works well in my experience.

The very much not basics - release management patterns

Grooming your backlog and keeping on top of release planning is an essential part of life on a Scrum team. Trello’s simple interface doesn’t push you into one way of setting up and managing your backlog or planning your releases, which leaves you with a number of options. As always, how you go about doing this will depend on your own situation and personal preferences. Below I’ve outlined a few different ways I think make sense and what the pros and cons of each are. For the most part I think what you choose to do will be dictated by how large/complex your project is.

The simple one - a single ‘backlog’ list

Something simple to get us started. You have a single list, the leftmost one on the board, called ‘To do’ or ‘Backlog’ with cards listed in priority order

Adding a ‘To prioritise’ list

The first improvement I’d suggest is a new list to the left of your backlog called ‘To prioritise’. This is where you (and possibly others) can log suggested enhancements. When you have time you can put these into the correct place in your prioritised backlog list.

The less simple one - adding release lists

Early on in the development of a new product it’s only sane to start saying “version 2” in response to a lot of enhancement requests. Once you’ve got a product live you’ll likely have a lot of versions planned for release and will want to plan them out in Trello. The simplest way to do this is to start with a list for each planned release working from most distant release on the left to the next release on the right.

If you have a small number of releases to plan out then this can be a nice way to set out what is coming up. If you’ve got a lot, and you have a lot of ‘in progress’ lists then your board may start to look a bit busy at this point.

The Product Management board - multiple lists on their own board

This is a nice way to solve a number of issues with having your backlog recorded alongside the lists you use for your main Scrum board. Maybe your development team would just rather not be mixing planned and current work, or maybe you want your own board to plan upcoming releases. With this pattern you create a Product Management board for your backlog and release planning and have a separate board or boards for teams to work on (the Scrum boards). This could be combined with something like the previous approach where you have a backlog of groomed cards ready for upcoming sprints on the Scrum boards so people can see what’s coming and a Product Management board holding future releases. The Scrum boards can have their own 'to prioritise' list for issues raised in the current sprint, the product owner can check these and prioritise them appropriately for immediate fix or for an upcoming sprint.

This approach also allows you to have multiple Scrum boards (ie 1 per team) being fed from a single Product Management board.

Top tip: You can send individual cards or entire lists from one board to another. Select 'Move' from the actions menu on the card or list. In this way you can plan out upcoming work on one board and transfer it to the relevant Scrum board when it's ready.

Some miscellaneous additions

Including notes and resources on your boards

Another common pattern is to have a 'Resources' list on the left of each board. Here you can have links to your CI server and other useful tools as well as personas and other documents the team may need regularly. If there are resources people on the team need regularly this can be a nice way to keep them to hand.

Template code review checklist

One smart thing I’ve seen some teams doing is to have a template code review checklist on a card in their notes/resources list. When they need to do a code review on a card they can attach the checklist from this template card (this is an option in Trello when adding a checklist to a card) and get the latest one. This way, if you make changes to the checklist in a retrospective you can be sure everyone starts using the latest checklist immediately.

Dealing with multiple boards

There are a few little tricks you can use in Trello to make your life easier if you're regularly using a lot of boards

Firstly, use the 'starred boards' function in Trello to flag the boards you use regularly. These will pop up to the top of the list saving you scrolling around looking for them.

Secondly, set different board backgrounds for different types of boards. So your product backlog boards might be green, your team sprint boards blue and any inactive boards grey. This makes finding the board you're after easier when using the boards menu.

And finally, if you've got loads and loads of boards consider organising them using Teams. This can help group large numbers of boards and users together when looking at the Trello boards page.

Useful plugins

Obviously (I would say this though :)), if you're after burndown charts and other reporting features for Scrum and Kanban teams I'd recommend checking out Corrello. It’s also got Cumulative flow diagrams, Cycle time stats, forecasts of when your next release will be completed and more.

Another useful addition is the Scrum for Trello browser plugin. This is a nice simple plugin for chrome, firefox and safari which lets you add story point estimates to your cards. It stores the points in the card title (which is compatible with Corrello).

If you like adding Work in Progress limits to your lists you can also get the Kanban WIP plugin (chrome only). This makes the lists go red if you add too many cards to them.

Trello business class is also worth taking a look at, their Slack and Github integrations are potentially very useful for any development teams using Trello and you get access to the full set of powerups.


That's it really, everything I've seen which works for Scrum teams using Trello. Trello is perfectly capable of running your Scrum process for you, just think how many teams still successfully use post-it notes on a wall. But a little planning up front can make things easier for you and your team.

[Side note: I didn't do this for the fun of it but because I've been building Corrello a tool creating Dashboards for Scrum teams using Trello and for Kanban teams using Trello, if you're an Agile team using Trello you should check it out :)].

About the author

Robin Warren is the founder and creator of Corrello, a dashboard tool for agile teams using Trello. Prior to that he was CTO for a small software company in the UK managing a couple of Scrum teams. He’s had a long interest in both software development and the processes which go around it, including several flavours of agile over the years.

Rate this Article