Trello Made Awesome Part III: From Backlog to Feature

We use Trello to manage development for Gander. Previously in this series we took a look at a a custom stylesheet and how we organize Trello for each sprint's work. Now we'll talk about how we manage stories before and after their sprint.

All stories begin their life in the backlog. The core of the backlog is a single list with a card for each story that's slated to get worked on at some point in the future. In our weekly grooming meetings we look at upcoming stories and assign story points to the ones that don't have them yet. We also take this time to come up with a "plan of action", a provisional list of tasks (stored as a checklist) for the story. This is a good exercise to get us all on the same page for how much work a story is, and saves time in planning.

We often find that we have a large number of stories grouped around a common end goal, like ActiveSync support. Especially when one of these groups is the most important thing to work on, it obscures everything else in the backlog list, which doesn't help anyone. When this happens we create a new list for the group, and create a placeholder card in the backlog that points to it. This way we can easily set the priority of the whole set of stories and see everything else that's going on.

When it comes time to add things to the sprint we pick the top several things from the backlog and create lists in the sprint board for them. Then we just move the backlog card directly into the sprint board and label it as a story. We take the plan of action and turn them all into task cards which automatically get added to the story's list. If we did our job right during grooming, then we're pretty much done. If there are more or different tasks that the story needs we make cards for those, and then the sprint begins.

Once a story is finished we move it off to the right side of the board. Like keeping done cards at the bottom of their list, this makes it easy to scan the board for what needs to get done. We also make a copy of the purple story card and move that into a verification board. This board has "To Verify" list that holds everything we've done that our product owner hasn't had a chance to do a final inspection on yet, a "Verifying" list that has the things he's currently looking at, and then a list for each sprint that we've completed for the things that were done and verified in that sprint.

The verification board also serves as a checklist of what we have and haven't deployed by using the last color, blue, to mark things that have been pushed to production. This makes it easy to write up change logs.

There we go. That's the entire story of how a card becomes a feature at Riparian Data.

Trello Made Awesome Part II: Lists, Cards, Labels

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.[1]

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!

Trello Made Awesome Part I: Life in Technicolor

Our development team adopted Trello several months ago for managing our work on Gander. In this ongoing blog series, we'll talk about how we've made it work for us in several ways that, in our most humble of opinions, are even better than the default setup Trello gives you. Up first, some CSS.

Very nearly every card in our Trello board has a label on it. It's great that Trello lets us do this, but it becomes hard to distinguish the different colors, especially from across the room during standup, or after a long day of hacking on email. Enter Scott's custom stylesheet that turns a Trello board so colorful I've seen peacocks get jealous: (Install it with Stylish or Stylebot or your browser's equivalent.) Now, even with just a glance from across the room, it's easy to see what's going on. Which lists are green, which are red? The board is expressive enough that it even starts to take the place of a burndown chart. Instead of graphing how well we're doing, we can just eyeball the board: is it the right color for this far through the sprint?

We think everyone should be using Trello like this, no matter what else you do. It sounds like a tiny thing, and the first time you see a board full of blocks of color it seems jarring, but trust us, it's great.

(Scott's currently working on a v2 of this stylesheet that can display more than one color per card using some sweet CSS gradients. We promise to update this space when it's done.)