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:

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:

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:

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.

Conclusion

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!