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.
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.
Sign up for Trello
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.
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.
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.
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.
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:
Editing card descriptions
Rendered card descriptions
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.
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:
Which will be rendered like this:
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
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.
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
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.
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?
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
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.
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
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:
Sending a card back for more work
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.
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.
Only 2 colors have a reserved meaning, the others can be used for your own purposes. The special colors are as follows:
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.
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.