CivicActions has been a virtual organization since it was founded, and we’ve adopted Agile methods–especially Scrum–for all of our projects in recent years. And since March 2012, we’ve adopted Trello as our go-to solution for managing virtual, Scrum projects.
We love the way that Trello lets you see the big picture. This concept is at the centre of Scrum: if team members don’t understand the big picture goals of a Sprint or a release, they don’t own their respective tasks in the same ways. If they don’t understand their work in relation to what other team members are doing, then they don’t collaborate as much, don’t cross-skill, and the team doesn’t improve.
We also love that Trello is feature rich without feeling bloated or bureaucratic, like many other project management tools. On most projects we use almost all of Trello’s features. With other tools, we’d often be just skimming the surface of features, squinting our eyes to ignore the clutter of functionality that wasn’t relevant to us.
After six months of using Trello for dozens of projects with virtual Scrum teams, we’ve learned a few things. Here are a few pointers that might help you get started with Trello, or help improve your use of it for your Scrum projects.
Tip 1: Use more than one board per project
Trello is great for the big picture view of things, since everything is on the same page. But there are potential downsides to using only one board (one big picture) for a project:
- as a Team member trying to focus on a task, sometimes you can’t see the tree for the forest.
- important stuff can get changed way too easily (“Hmm, who just dragged a card from the Product Backlog to the Sprint Backlog in the middle of the Sprint!?”).
- boards can get too wide, with too much horizontal scrolling.
- as a Product Owner, there’s all this tempting stuff in the Sprint Candidate list that keeps frustrating you about it not being in the sprint. Part of the goal is to prevent distraction during an active sprint.
Since in Scrum we have two distinct modes–active development (the Sprint) and reviewing/planning–I suggest using one board for the Product Backlog and Sprint Planning, and another board for each Sprint. When a product owner approves a card, move it from the Product Backlog board to a Sprint Backlog on a separate Sprint board.
The Product Backlog board
We like organizing our Product Backlog board into the following lists of cards:
- Ideas. No detail, just a stub for the product owner to develop an idea.
- Requirements Gathering. A list to flesh out user stories and desired functionality.
- Ready for Estimating.
- Sprint Candidates. For tickets that have been estimated.
On this board, the Product Owner is responsible for prioritization of cards within each list, with the highest priority cards always on top.
The team moves cards from Ready for Estimation to Sprint Candidates during a Sprint Planning meeting. If user stories are not complete, cards get moved back to Requirements Gathering. Here’s a template.
The Sprint board
Cards should only appear on this board if they have been approved for a specific sprint by the Product Owner.
- Sprint Backlog. This is ordered according to priority determined by Product Owner.
- In progress.
- QA bug reports. This prevents QA testers from moving cards back to the Product Backlog, or straight into “In progress”.
- Ready for QA release. Optional, use this lists for cards whose tasks have been completed by engineers, but where the code hasn’t been deployed to a QA environment.
- Ready for QA.
- Ready for Release.
Here’s a template for a sprint board.
Tip 2: Track your hours against estimates!
The extension provides a set of Fibonacci-sequenced buttons for adding estimates to cards, then it adds up the all cards on each list and displays the estimate per list, as well as an aggregate estimate for the whole board.
If you have a sprint on each board, you can easily track how many hours or user points you’ve added to a Sprint during a Sprint planning meeting.
After a Sprint is kicked off, you can track hours per card by adding to a number in a square bracket in the card’s title. This number also gets added into an aggregate that appears in lighter blue at the top of each list, and at the top right, which provides an immediate sense of the current sprint burndown.
At CivicActions we mostly use hours estimates. It’s unclear to me how our Trello methods would work for user points. If you have experience with both user points and tracking hours via Trello, let us know in the comments!
Tip 3: Use checklists for tasks whenever possible
As a Team member working on a task, it’s much easier to parse the checklist for what’s next than it is to read through the prose of a card description, or the comments. Similarly, as a QA tester, it’s a lot easier to read and test Acceptance Criteria if they’ve been outlined as individual checklist items.
I like having a checklist on each card for each of the following: Acceptance Criteria, Implementation (the task breakdown for developers), Tests (for automated or unit tests), Deployment tasks, etc. If any individual checklist item grows too big for one card, it can be split into its own using the great “Convert to card” feature.
For cards that have more than one member assigned, we find it useful to name the person responsible for each checklist item.
For estimating, we also find it useful to include an estimate each task on the checklist, before adding them up to the aggregate estimate that the in the card title.
Tip 4: Take card assigning seriously
You can assign team members to cards by dragging and dropping them onto the card, or on the back of the card. Don’t be tempted to add more than one member per card. This confuses who is actually responsible. If other members of the team want to stay involved or informed, they can subscribe themselves to the card. Product owners who like to follow progress can be tempted to subscribe to every card, or entire the board all at once. This is TMI! “Need to know” is the key to productivity here.
If you’re an engineer and you’re done with a card and you’re moving it to Ready for QA, remove yourself. If you already know who is going to QA, assign the card to them.
If you’re a QA tester, remove yourself after you’ve finished QA. Assign it to the engineer who worked on it, or to whoever’s in charge of assigning bug fixes.
Trello offers a page that shows all of a user’s cards, on all their boards. Very usefuly if you’re working on more than one project at once!
Tip 5: Use a Trello board for the Sprint Retrospective
A Trello Board can be a great Sprint Retrospective tool. We’ve published an Sprint Retrospective Template, feel free to copy it!
We’re curious to hear from others using Trello for Scrum. Our process is still evolving, I’ll post comments below as we continue to learn how to make the best use of it.