The secret shared by amazing software teams is that they all have a game plan for building great software. That game plan starts with the right strategy for taking an idea and transforming it into useful features. Of all the tools available for this, the free tool Trello, can provide everything needed to manage software projects, assuming you know how to use it effectively.

Trello: It's got what developers crave

The goal of any project management tool is to stay out of your way and let you get things done. Few accomplish this as simply as Trello, and without proper usage all will fail. Based on years of experience, as well as numerous published accounts, this guide will help you provide an environment that will let your developers excel.

What do developers need to perform at their best?

  • Some limited freedom to choose what to complete
  • A clear indication when work is ready to be done
  • A plan for getting feedback when work is not clear
  • An approval process once work is complete, so they know when work is accepted
  • Accountability after work is done to manage delivery and revisit past work

Step 1: Setup your free Trello account

Go to and click the signup button.

Trello has made a public committment to remaining free to use "forever" so you can feel safe using it with your project if cost is a concern.

Sign up for Trello

Step 2: Setup your Product Development board

Click on the plus sign (+) next to your profile icon and create a new development board. The default shows 3 lists: To Do, Doing, and Done. You can rename or delete the defaults, in the end you're going to create 6 lists: Backlog, Next, In Progress, Staged, Approved and Live this week.

Setting up development lists


Holds all scheduled tasks. It's a space to hold ideas and a place to develop ideas into actionable items until they're ready to be started.


Contains tasks ready to be completed listed in order with most important tasks at the top, as determined by the project manager. Tasks may be assigned to individual developers at this stage.

In Progress

Once a developer starts a task, it will be moved to this list to show that work is progressing.


After a developer's task is complete and ready to be reviewed by the project manager or client, it will be moved here. If changes are needed, move the task back to Next with comments. Otherwise, move the task to Approved.


Once a completed task has been reviewed and accepted, move it here. This holding area informs the development team that this work is ready to be finalized and delivered to production.


(Date for monday of the week, example: Live 01/06/14)

Developers will move tasks into this list from the Approved list as they are delivered to production and are part of the final product. At any time, the Live list for any week can be archived by clicking the drop down arrow next to the list title. Create a new Live list each week.

Step 3: Add Trello cards to Backlog

Start entering all of the things you need to do into the Backlog, each as a new card. All cards start as a simple title, so it's important to capture enough information in the title right from the beginning.

Creating new cards

Each card title represents the smallest noticable change for each feature in a short descriptive sentenance using about 12 words or less. When in doubt, it's best to use a longer title than a title that is too short.

Checklist for creating great cards:

  • Does the card describe a single feature? If any part of this task can be delivered and approved without completing the card in full, then make a separate card for each piece.
  • Does the card clearly indicate who should be able use the feature? For example, if the feature is available only to authenticated users, the title should make that clear.

Examples of great cards:

  • As an admin, when I'm editing details for a user I can click a button to disable and enable the user's account
  • As a logged in user, when I visit the homepage I will see a "My Profile" link in the top right

Examples of poor cards:

  • User administration
  • Finish onboarding
  • Access control lists

Step 4: Add details to cards

Before your team can start working on cards, you'll need to add details to each of them before you moving them to Next. Use the guide below as a resource to help you expand each card into fully specified work that can be completed by your developers.

Protip: How to write specs that developers love

Developers respond well to cards that give very specific and detailed instructions. What appears to you as obvious may not appear that way to a developer, because he/she works with the internals and details. It's up to you to specify how the external parts (the parts you see and touch) operate. Provide clear instructions that would answer each of the following to make a great card:

  • What type of user is performing the action?
  • On which page or view will the user find this feature?
  • What is the action the user will perform?
  • What are the inputs the user will provide, or the steps the user must take?
  • What are the expected results of the action?

Editing card descriptions

Rendered card descriptions

Fill in the description

Card descriptions should provide enough detail to allow someone new to the project to understand the requirements without questions. They start off simple, with 1-2 sentences and can grow into full specifications as needed. If your description is more than a couple sentences long, create a Google Doc "spec" file and add a link to the Google Doc as an attachment to the card.

Adding links to descriptions

When your description grows too long for a card or is subject to revisions, use a Google Doc to hold the full specifications. Once you have the doc, copy the share url and include it as a link in the description of your card. Links can be added to descriptions using the following format:

[Link title](

Which will be rendered like this:

Adding development effort estimates (optional)

Estimating software features is a very difficult task. To avoid wasting time on estimates that cannot capture the full scope of the work, estimates are based instead on a scale from 1 to 5 where 1 is trivial and 5 is quite difficult or there is very much unknown. Through years of experience we've learned that while a developer can usually estimate the relative effort required for a task, it is difficult to reliably associate that effort with the amount of time required to complete, so it's esstential to not spend too much time estimating. Instead, it's best to create many small tickets and focus on getting them done quickly.

Adding effort estimates

When in doubt about the effort required, a developer should always estimate higher. It's better to deliver early or have opportunity to get more done than it is to fall behind or introduce unexpected delays in finishing features.

Step 5: Getting work done

With your cards fully described, you can now schedule them for development. To do this, the project manager should drag each card from Backlog to Next, placing them in priority order. Cards will be completed in roughly top down order by the development team.

Scheduling cards to be completed

Now your team is ready to get started. Each developer will login with his/her own trello account and choose items from the Next to complete. While you've set a priority, the developers should be allowed to choose from the list with some freedom, prioritizing by the order of cards in the list. This will allow the development team to work efficently and focus on maximizing results, instead of following a rigid development plan assigned by someone who may not know the internals.

What if a task is urgent?

When you need to mark a task as urgent, assign it a green label, so developers know that the task on the card is critical and should be addressed ASAP. Please use this label sparingly.

Marking a task as urgent

Starting work

To start working on a card, a developer will move it from the Next column into the In Progress column and assign the card to himself. At the same time, he/she will assign an estimated date of completion for the due date.

It's important to remember that by definition, the estimated date of completion may not reflect the actual date of completion. If development starts and it becomes clear that the work requires more time, then the developer should update the estimated completion date, leaving a comment reflecting the change.

Starting development work on a card

Seeing a card on the In Progress list assigned to a developer means that work is being done on that task. But what happens if progress needs to pause because feedback is needed?

Requesting feedback

In an ideal world, all cards would be perfectly specified and developers would never need to make hard decisions on their own. In reality, you put an immense amount of trust in your developers to make decisions for you that align with the bigger goals you have for the project. Some of these decisions cannot be made without input from the project manager. When that happens, the developer will block the task for feedback by assigning a red label and @mention you in a comment.

Requesting feedback on a task

Once a task has been blocked, it can remain on the In Progress list, but must retain the red label until the task is unblocked and work can begin again. Resuming progress on a blocked task is as simple as removing the red label. The comments should never be removed.

When you @mention another person in a comment, they'll receive an email with details from the mention.

Notification received when mentioned

Step 6: Delivering new features to production

When a developer finishes a card and the completed work is uploaded to the staging or test location, then he/she will move the card from In Progress to Staged where the work can be reviewed and either approved or kicked back with a comment for more changes.

In order to keep the project manager updated about new cards added to the Staged list, developers should add the project manager to the card at the same time that they move it to the Staged list.

A developer marking a card as complete

By adding the project manager to the card, you'll generate an email notification from Trello which lets the project manager know that the card has been completed, and code is in the testing location to be reviewed.

Approving completed cards

When a card is completed and approved, then the reviewer should leave a LGTM (Looks Good To Me) comment and move the card to the Approved list.

The developer will move the card from the Approved list to the Live list when the code is deployed to the production or release environment.

Approving completed work

When more work needs to be done

Sometimes when a card is delivered, it needs more work before it can be released to production. Maybe an issue is found in testing, or it doesn't provide the experience desired. When this happens, the following things need to happen:

  1. The project manager/reviewer leaves a comment describing the additional changes needed.
  2. If a response is required, then use a @mention.
  3. The card should be moved back to the Next list. If priority is an issue, it should be labeled as urgent (green.)

Sending a card back for more work

Frequently Asked Questions

How many cards should I have?

Generally, having too many cards is better than having too few. Not having enough can result in loose ends or gaps in your project, or cards that are too big to be completed quickly. So be generous, and create lots of cards. Developers love checking things off a list.

When are due dates assigned? What happens to due dates after work is done?

Developers will assign a due date when work begins as a best-guess estimate for when the work will be completed. If a due date needs to change while a card is In Progress it should be updated as soon as it's discovered.

Once work is delivered, remove the due date. This will prevent "due soon" and "overdue" emails from being sent and will allow the team to receive those emails when they are important.

If a task is due by a certain date, the project manager can assign the due date when the card is moved to Next.

What are the labels used for?

Only 2 colors have a reserved meaning, the others can be used for your own purposes. The special colors are as follows:

  • Red: Card is blocked and needs feedback to continue
  • Green: Card is urgent and should be addressed as soon as possible.

When are cards archived?

No cards are archived individually unless they are to be deleted and never completed. Live lists may be archived after several weeks or at a time of your choosing.

What's the best way to get feedback on a card?

Always @mention someone when commenting on the ticket if you want them to respond. Comments without a @mention are assumed to be comments to yourself.