How Optify Uses Trello for Kanban

As Chris mentioned in a his post on trimming the fat from Optify’s product development process, Optify has moved to a Kanban product development process. We had previously been using VersionOne as our Scrum tracking tool and felt the need to migrate to a simpler and more streamlined tool to pair with our simpler and streamlined process. After evaluating several different options, we arrived at Trello as the best tool for the job. Trello is intentionally multi-purpose. As Joel Spolsky described it, Trello is “…Kanban boards. For developing software the agile way…but it’s also for planning a wedding, for making a list of potential vacation spots…” This makes Trello a great general purpose solution, but it’s missing a few key features that would make it really shine for a Kanban. We’ve managed to work around many of these limitations via a combination of browser plugins, conventions for naming cards, and external tooling that uses Trello’s API for reporting.

Our Kanban board is divided into the following swimlanes:

• Planning – Stories we’d like to start soon that need additional requirements, specification, or wireframes before they can be added to the Ready Backlog
• Ready Backlog – Fully-specified stories that are ready for developers to pick up and start. Stories are maintained in order based on business priority, and the team works from top to bottom from this list
• On Hold – Stories that are temporarily shelved. On Hold is generally unused except for cases when a P1 defect may bump an In Progess story to On Hold
• In Progress – Stories that are actively under development. Each story has (at minimum) a developer and a product owner assigned
• QA – Stories that are currently undergoing functional testing
• Acceptance – Once a story has been developed and tested, it moves to Acceptance for final review by the product owner
• Deployment Ready – Stories staged for deployment
• Deployed MM/DD – Stories deployed on a particular date. We usually keep the most recent two or three deployment lanes around for visibility before they are archived

Once we had the swimlanes defined, the next step was figuring out how to limit the work in progress. To accomplish this, I wrote a simple Google Chrome plugin that allows you to specify a WIP limit in the list name by placing it in brackets (e.g. “In Progress [8]“). Once the number of items in the list hits the specified limit, the list is highlighted in yellow. When the count exceeds the limit, the list is highlighted in red making bottlenecks in the process highly visible, especially when our daily standup is staged in front of a large-screen TV with the Trello front and center.

We also needed the ability to annotate each card with the story points (estimate) the team provided during our weekly sizing meeting. For this, we turned to another Chrome plugin Scrum for Trello. This plugin provides a set of buttons in the card view that allow you to add the story points to a card with a single click. Finally, we needed a way to identify the feature group(s) associated with each story. We’ve stuck with the convention of specifying the feature groups in brackets after the story name (e.g., “Search for contacts by email address – [Contact Manager]“).

We’re using this data to report on our progress on the metrics below by compiling data via the Trello API.

• Velocity – The sum of story points deployed per week
• Maintenance vs New Feature Work – Points per week spent on new features versus bug fixes and maintenance
• Product Focus – Story points allocated by feature group

We plan to blog in greater detail about this process as it evolves, including how we manage the product backlog and bugs in Trello, and how we’re using the Trello API to build custom reports.

Does your team use Trello or another tool for Kanban? I’d love to hear about your experiences and lessons learned!