Using Trello Labels to Track Software Estimates

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.

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.

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.

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.

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.

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!