Using Trello for Software Project Management


Software project management is not as trivial as it may seem at first sight. Unlike other projects with tangible outcomes, software cannot be clearly specified up front and any monolithic waterfall approaches are doomed to fail. Agile methods have proven to be more suitable for software. What happens though if the team works remotely? How do you deal with the project board? How do you hold the standup meeting? Web based tools are the obvious answer. Hence we examined many of them and we concluded to Trello, Asana, and Targetprocess3 (Tp3) as the best choices. Key features were simplicity and not very steep learning curve, support for mobile devices, and of course a free plan for small teams (necessary for peace of mind in case you have chosen the wrong tool). Based on these criteria we selected Trello for the team. I’m also using Asana as a personal todo list, according to the suggestions of ‘Getting things done’ by D.Allen (details on Asana in a future post). Tp3 is used in an experimental mode in order to learn it (much more complicated and complete than the other two) and possibly use it in the future with a bigger team.

Having settled with Trello, we had to decide about the process and the lists to be used. Trello provides enough flexibility and does not promote a particular methodology. So after some projects, trial and error, some time of despair, we managed to find the structure that fit our needs. We found very useful advice in many articles around the web explaining how other teams are using Trello successfully[1],[2],[3]


We are using the following lists (columns):

STANDUP MEETING: Contains one card for each sprint. The Goals of the sprint are set here. Team members should add a comment daily explaining briefly ‘Y: what I completed yesterday’, ‘T: what I’m going to do today’, and ‘P: any problems I have’.Each answer should not exceed 2-3 lines and any additional details should be added to the respective cards. This process is an imitation of the real standup meeting and it is very important for remote teams which cannot meet physically, not even via skype because of geographical limitations, time difference, personal obligations, etc. At the end of each sprint we add a final retrospective comment.

IDEAS: Ideas or suggestions that need to be examined in order to become features or not.

FEATURES: The functional requirements of the system. Each feature is divided to a checklist of items (user stories) which can be implemented separately. As Trello does not provide links between features and user stories, we assign to each feature a ‘serial number’ using a hashtag (e.g. #002) which can be used in user stories, tags, or bugs as a reference to the feature.

TASKS: Non functional requirements of the system. Work to be done in order to support the functionality of the system.

BUGS: Errors, problems, malfunction identified during testing or reported by the clients. We use hashtags to indicate the status of the bug: #new, #accepted, #rejected, #solved.

BACKLOG: A list of the ‘user stories’ to be implemented. User stories are added here as they are identified and we don’t need a detailed analysis to find every possible user story.

SPRINT: User stories, tasks, and bugs to work on during the current sprint. These are selected at the initial meeting of the sprint and if possible team members are assigned. If all selected cards are implemented ahead of the sprint end date (actually this rarely happens), then we select more from the backlog, the task and the bug lists.

DOING: Cards we are currently working on. This list should contain a minimum number of cards, ideally one card per team member.

DONE: Cards of user stories and tasks which are completed. A card is assumed complete if all the checklist items are implemented and tested.

FIXED BUGS: Cards of bugs that are fixed and tested.

A sample board with our columns can be found here:

We also use colour code to indicate a card’s type. This is very important when the card leaves the initial list and goes to sprint, doing, or done. The code appears on the following image:


Order of cards is significant and indicates the priority in which a card should be examined and processed. The order is rearranged during the retrospective at the end of each sprint.

We have tried this method for a team of 2-3 members on small projects of approximately 6-months duration and it worked perfectly. Now we apply it to long term projects and we expect to have the same amazing results. However, the larger number of features and tasks might be a trouble given Trello limitations.

4 thoughts on “Using Trello for Software Project Management

  1. Thanks for sharing, it’s good to see how other teams work.

    We also use Trello at On the Beach for our agile product development team. We’ve moved away from Scrum and towards continuous pull and delivery and limited WIP. Stand Ups focus on the stories, starting downstream (closest to Live) and moving upstream. We generally only talk about those stories with any blockers, issues or impediments. We make full use of the labels, attachments and task lists and also the comments to cover off testing feedback etc. Each team uses Trello in the way that suits them best (they’re empowered and accountable to deliver a feature or product by whatever ‘process’ works for them). Most have a ‘Current’ board, showing what stories they’re aiming to complete this week (loose timebox) and a number of feeder boards covering such categories as features (normally still at Epic level), bugs, technical work. Once a week they hold their retrospective and then decide (with the Product Owner who sits with his or her team) which stories from the feeder boards to bring into the Current board next. We work very much on building and shipping the minimum viable product (MVP) as quickly as possible, then getting real user feedback and iterating to improve until the Product Owner tells us we’ve delivered enough business value, which triggers a kick off discussion for the next roadmap in the schedule.

    Trello works well for us. Even though our teams are co-located (so they could use physical boards) they prefer Trello. This was a whole team decision, not mine (as the Agile Coach) and I’m happy that they’ve taken ownership of how best to work in a fast-moving, dynamic agile way.

    1. Thank you Paul, your feedback is very important and it confirms that the best things with Trello are simplicity and the freedom to build the lists you prefer.
      I will post updates in the future as we will be using Trello in projects of larger scale.

      PS. Glad to see Crete, where I come from, included to ‘onthebeach’ 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: