Using Trello Labels to Track Software Estimates

How I use labels to track estimates, measure capacity, and keep scope creep under control. Part 2 of my series on managing software projects in Trello.

This is the second part of my ongoing Trello series. To quickly recap Managing Software Projects with Trello, Part 1: I run all of my software projects with Trello boards made up of Backlog, This Week, In Progress, Ready for Review, and Done lists. Cards representing tasks or features make their way through these lists from left to right.

Trello board
My typical Trello layout and workflow.

In this article I want to go beyond the basic board setup and show you how I use Trello’s labels feature to streamline my projects. Specifically:

  • How I measure progress and track estimates using labels
  • Why labels are a good fit for scoping discussions
  • Dealing with tasks that haven’t been estimated yet

Using labels to represent estimates

In another post I explained my system for estimating software projects, which involves using dots to assign relative effort/risk. The main takeaway is that sorting tasks into a few broad categories is more effective than assigning hard numbers.

It’s no coincidence that broad categories map perfectly to Trello’s concept of labels. Here are the labels I use:

  • Green for easy tasks (•)
  • Yellow for medium tasks (••)
  • Orange for difficult tasks (•••)
  • Red for “epic” tasks (••••)

Trello uses vibrant, easy to identify color swatches for its labels, which means I can quickly glance at a Trello board and get an idea of the amount of work it represents.

Trello board
No numbers or charts needed – color tells the story.
(Just to clarify: my Trello cards aren’t normally blank! I’ve redacted the card text from the screenshots in this article.)

Determining weekly capacity

Every Monday I need to make a decision on what I can reasonably accomplish in the coming week. Looking at the labels of the previous week’s accomplishments (i.e. the cards in the Done list) and counting the number of green, yellow, orange, and red tasks gives me a rough, “good enough” idea. My capacity for the coming week should be similar.

Trello board
Last week’s accomplishments and this week’s goal should have similar scope.

Negotiating priorities

The simplicity of the color system means that I can easily negotiate with my clients on scope and priorities. Two tasks of the same color are interchangeable: if the client has a new feature idea, and that idea is “orange”, we can swap it in for an existing orange card, keeping the scope roughly the same. This is a good way to keep feature creep under control.

Trello board
Tasks of the same color can be swapped, keeping the week’s scope unchanged.

Of course, a one-to-one swap is not always possible, so I will often use powers of 2 to roughly equate tasks of different colors:

1 red = 2 oranges = 4 yellows = 8 greens

For example, when determining the scope a week’s work, the client and I may decide that 4 green tasks (“low-hanging fruit”) may offer more value then spending time on one big orange task.

Accommodating new tasks

Finally, I sometimes use one more label to represent the absence of an estimate:

  • Blue for “needs estimate”

During an active project, the client and I will be adding new cards to the Trello board all the time: new feature ideas, breaking apart an existing task that proved more difficult than expected, bug reports from customers, etc.

Trello board
I’ll tag new tasks as blue when they are added to the board.

If the implementation of a new card is immediately obvious, I’ll assign the appropriate green, yellow, etc. label. Otherwise I’ll label it blue as a reminder that it needs further investigation before it can been scheduled.


Trello was not specifically made for project management, so it lacks fancy reporting features and detailed task metadata. However, I see this as its strength, not a weakness. Especially for nimble software projects with small teams, Trello’s approach is pragmatic and easy to understand. Labels are a perfect example of this simple effectiveness.

Next in this series: how I represent hierarchies in Trello’s otherwise flat system of lists. Thanks for reading!

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


Generate your next Rails app interactively! This template includes production-ready recommendations for testing, security, developer productivity, and modern frontends. Plus optional Vite support! ⚡️

Updated 7 days ago


A friendly CLI for deploying Rails apps ✨

Updated 1 month ago

More on GitHub →