Using Trello Boards to Organize Software Projects

An introduction to how I use Trello boards and lists to organize my freelance projects. Part 1 of a series.

Trello is a fantastic online and cross-platform tool for organizing ideas. In this article, I want to show you how I set up Trello boards for the day-to-day management of my freelance Rails development projects.

I have heard nothing but positive feedback about Trello from my clients. They value being able to see the progress of the project at a glance, and the boards make it clear where and when their feedback is needed. In my experience, this setup strikes a good balance: enough structure to keep everyone informed, but not so much friction that it slows down development.

I hope this article gives you a better idea of how I use Trello; perhaps you will find some ideas to apply to your own projects, too!

My typical board

I set up each development project with its own Trello board and create these lists:

  • Backlog
  • This Week
  • In Progress
  • Ready for Review
  • Done

For large projects with lots of integrations or a complex release processes, I might also add:

  • Blocked
  • Pending Next Deployment

Each list contains cards that represent tasks, features, bugs, or ideas. Prioritizing and tracking progress on these cards is as simple as dragging them from one list to the next. It really doesn’t get much simpler than that!

Trello board
My development project boards on Trello tend to look like this, albeit with many more cards.

Here’s how I use each list:


At the start of the project, all cards begin in the Backlog list. This list represents everything I aim to accomplish during the project, sorted by priority.

However, as carefully as I plan a project, or as confident as my clients are in their requirements, inevitably those plans will change. New requirements will be discovered or be proposed. Priorities shift. For a project to be successful, it is important to take these changes in stride.

I encourage my clients to add new requirements, feature requests, and changes as cards to the Backlog list as soon as they arise. Regularly during the project, perhaps in a quick ad-hoc phone call, we’ll review the list and decide which of those new ideas are feasible. We might discuss:

  • Which ideas are highest priority?
  • Are any urgent?
  • Will adding these new tasks increase the scope, and thus the budget?
  • Can we drop or postpone any existing tasks to accommodate the new ones?

This process ensures that the highest priority items will always be at the top of the Backlog list.

This Week

Every week, first thing on Monday morning, I’ll take the topmost (i.e. highest priority) cards from the Backlog and move them into This Week. I’ll make an informed guess as to the number of cards that can “fit” into This Week, based on previous estimates, the complexity of the tasks, and observations of how fast the development progressed in prior weeks.

The This Week list is not set in stone, but it does give the client a good idea of what I can accomplish and what to expect in the coming week. This means fewer surprises and happier clients.

In Progress

During the week, whenever I am working on implementing a particular feature, carrying out a task, or fixing a bug represented by a card, I will move that card to In Progress and put my avatar on the card.

This is a low-touch way of keeping the client informed of exactly what I am working on at any given time: no tedious status meetings or taps on the shoulder needed. For large projects with many collaborators, putting a face to each card explains who’s doing what, and keeps us from stepping on each other’s toes.

Ready for review

Once I complete work on a card, I move it to Ready for Review and notify the client. At the client’s next convenience, he or she can go down this list and provide feedback. This step is critical to delivering a quality final product, so I do my best to attach everything the client needs to the back of the card, like screen shots or recordings, acceptance criteria, and testing steps.

Another way to think about the Ready for Review list is that it becomes the client’s “to‑do list” of deliverables that are waiting for feedback. For super-busy clients with many other commitments, their use of Trello can be as simple as logging in a few times a week to review this list.


If for some reason I can’t complete work on an important task due to circumstances out of my control, I’ll inform the client immediately and move the card to the Blocked list. This is rare, and therefore in most of my projects the Blocked list isn’t necessary.

For some clients, a Blocked list can come in handy if there are inter-team dependencies or layers of management approval that may slow things down. Having a Blocked list in these cases allows us to visualize where those slowdowns are happening.

Pending Next Deployment

In most cases, once a feature or task is complete and has been reviewed, I move it straight to Done. But some features need special attention or scheduled downtime during deployment. In Rails apps, this could be a database migration. Or perhaps there is a security update that requires restarting critical services.

If a project requires it, I’ll use the Pending Next Deployment list as a “holding area” where these cards wait until a maintenance window can be scheduled.


When a task is done or a feature deployed, I move the card to the Done list.

Since a single Done list will grow and grow to become dozens of cards over the course of a multi-week project, I create a new list for every week. For example, during the fourth week of a project, the board would have four Done lists, named like this:

  • Done (Week of April 6th)
  • Done (Week of March 30th)
  • Done (Week of March 23rd)
  • Done (Week of March 16th)

(Putting older lists at the end means they naturally get shoved off the right edge of the screen and don’t clutter up the board.)

Not only do multiple Done lists keep things nicely organized chronologically, they give clients a great way to view accomplishments and measure progress. Trello boards are stored in the cloud and archived forever, so the Done lists are a nice reminder of what was delivered.

Rinse and repeat

Each week I repeat the process: review the Backlog and set a goal for This Week; then see that each card travels through In Progress→Ready for Review→Done. At any point, the Trello board represents a good snapshot of what’s on deck, what is stuck or in progress, and what has been accomplished. It also makes expectations and responsibilities crystal clear, which is key to any successful project.

That’s all for now…

So that’s what my typical Trello board looks like. Are your boards similar?

Trello is really exciting and I have much more to share, but this article is already quite long. I’ll wrap up for now with some ideas I have for upcoming topics in my Trello article series:

Trello may not work for all sizes of teams or styles of projects, but for my freelancing business it has been the perfect fit. What’s been your experience? Any questions you’d like me to address in this series? Feel free to shoot me an email.

Share this? Copy link

Feedback? Email me!

Hi! 👋 I’m Matt Brictson, a software engineer in San Francisco. This site is my excuse to practice UI design, fuss over CSS, and share my interest in open source. I blog about Rails, design patterns, and other development topics.

Recent articles

View all posts →

Open source projects


App template for Rails 7 projects; best practices for TDD, security, deployment, and developer productivity. Now with optional Vite integration! ⚡️

Updated 1 month ago


A friendly CLI for deploying Rails apps ✨

Updated 20 days ago

More on GitHub →