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.