A few quick guidelines on my conventions when using Trello. These are not rules. Trello doesn't enforce a structure allowing each project to adapt to it's needs. But this is a good place to start:
- Unquoted - Any card being added to the project which is not in the statement of work and not a bug related to work covered by the statement of work goes here. The goal of this list is to avoid scope creep. If scope is being added we want it to be an explicit decision with an explicit cost estimation. The person creating the card should try to estimate the cost (or get someone to do so for them). The client can then choose to move it to the Todo list if they want to increase the scope. If they choose to hold off for now this list provides an excellent idea source for future rounds of development.
- Todo - These are tasks that need to be done which are not in active development.
- In Progress - These are tasks that are actively being worked on by a developer. If you are not actively working on it move it to the appropriate list. This provides a quick glance of what everybody is working on.
- Code Review - Once a task is completed and pull request created a card should be moved here. Periodically review the cards in this list to see if there is anything you can review and merge.
- QA - Once code has been merged it should be placed this list. This provides a list of items the client can review to confirm they complete the goal. If there are bugs in the implementation create a new card to track the bug through the process. Only kick it back to an earlier list if it completely misses the goal or is so full of bugs that it is not worthy.
- Complete - Once the client has does the QA work it should be moved here to serve as an historical record of what is done.
- Feature - Give this label to new functionality being added to the app.
- Bug - Give this label to any card designed to resolve a bug. This label is red while Feature is green. If our screen starts showing a lot of red instead of green it means we are spending more time fixing problems than moving forward and need to evaluate our process.
- Needs Steps - This is added to any Bug card which does not have steps to reproduce. We highlight these as the client, tester, project manager can provide these which helps prevent spending developer time tracking down the steps to reproduce. If a bug card does not have a section in the description labeled "Steps to Reproduce" it should get this label. Non-programmers involved in the project can look for these cards to try to provide these steps to help the programmers out.
- Blocked - If you have started work on a card but got blocked mid-way put this label on it. This will highlight the need. If a card has not been started but is blocked by another card it does not need this label. This label is meant to just highlight cards that have consumed resources that we wish to focus on to capitalize on the resources it has consumed.
- Design Needed - If the task needs some sort of mockup or design label it with this card. This will allow a designer to easily see where they can help out.
- The estimation cost are prefixed in the title in parentheses. So "(6)" means 6 hours are estimated.
- As you work on a project, note hours spent on a task by adding those hours to the title (in addition to the Harvest for accounting purposes). This allows us to easily see what tasks are over and what tasks our under allowing us the ability to modify scope on this tasks or other less important tasks. So if you billed three hours on a 6 hour task it should say "(6/3) ....".
- Try to avoid creating task lists on a card itself. Create individual cards. This way each task can be tracked individually through the process.
- If a card is blocked by another card (regardless of if it is started) note the other card that blocks this card. This helps determine what to work on next.
- Put your face on a card if you have done work on that task.
- Link to any commits/pull requests related to the task.