We use Trello to manage development for Gander. In Part I of this series we showed off a stylesheet that filled Trello with color. Now we'll talk about how we arrange our main development board to manage our sprints.
The baseline for using Trello to manage software seems to be the official Trello development board. Most other people I've talked to that use Trello do something similar. In this board, lists are for states (idea, in progress, done), cards are for stories (better search, copying a card) and labels are for types (bug, feature, infrastructure). We tried that, and hated it.
Instead, we use lists for stories, cards for tasks, and labels for states. The rest of this post is the details about how that works, but if you just take that sentence and forget everything else, you'll get 90% of what we're doing.
When we plan a story into a sprint it gets a new list ("Frob all the widgets"). The first card in the list is labeled purple (Story) and holds all the information that covers the entire scope of the story: a more informative title, a description of why we need to frob the widgets, the acceptance criteria for when we can tell the widgets have been sufficiently frobbed, how many story points we've assigned to widget frobbing, etc. This card stays at the top of the list and doesn't change much once we create it.
Then we make cards for each task in the story. These all start out with no label (effectively "To Do"). The structure of these is pretty freeform. Some of them might have just a title if the task is simple enough ("Make a FrobController with stub `frob` and `unfrob` actions"). We commonly put checklists on testing tasks to list specific tests that we know ahead of time we need to cover, but it's not required. These cards tend to grow as people work on them. We'll have discussions in the comments, attach mockups or error screenshots to the card and whatever else we need.
Once we start working on a card, it gets a team member assigned to it, and labeled yellow (In Progress). This is when most of the action happens on the card. Once the work is done we turn the card orange (Needs Review) and start a code review. As long as everything goes smoothly, the card gets labeled green (Done) and the task is complete. We move the card to the bottom of the list so that it's always easy to find the tasks that need to get worked on (especially for stories with lots of tasks that grow a scrollbar). If something goes wrong and we can't work on a task it gets marked red (Blocked). Cards never turn red without also getting a comment explaining why they're blocked. If the cause is another task or story, the comment has a link to the card.
And that's about it. When we combine this with the stylesheet from last time, the health of a sprint becomes available at a glance. If the board is turning green, the sprint is going well. If too many things are red, we're being stopped from getting our work done, and need to fix that before doing anything else. Too much yellow means the team is trying to work on too many things at once, too much orange means we've been slacking on code reviews.
1: Which isn't to say that it's bad, or that anyone who organizes their board this way is doing it wrong, but just that it didn't work for us at all. If it works for you, great!