Tracking and Reporting on Optify’s Kanban Process

In a previous blog post, I discussed Optify’s transition from a traditional Scrum development process to a Kanban process. As part of that transition, we also migrated from VersionOne to Trello as our Kanban tracking tool. Trello is a great multi-purpose tool, and with a few plugins and conventions, works quite well for Kanban, however, the lack of reporting is going to be a major roadblock for many organizations. Fortunately, Trello’s excellent and well-documented API provides access to the raw data backing your boards enabling you to build your own reports.

There are three key reports that we needed to be able to build from the data in Trello.

1. Velocity Trend – The velocity trend is an important indicator of the amount of code being shipped to our customers. Since we’re deploying weekly, we tend to look at a six week rolling average and compare it with the prior six weeks to determine if we’re trending upward, downward, or holding steady.

2. Feature Group Allocation – The feature group allocation report helps us quickly visualize the level of focus of the product development team. With this report, we’re able to quickly answer questions such as: “Are we managing the backlog in a way that aligns our efforts toward our key product initiatives?”, and “How much budget are we spending on feature work vs bug fixes?”.

3. Cycle Time – The cycle time report helps us measure how much time (on average) a story or defect of a given size takes to make it through development, QA, and ultimately deployment to production.

Since the content on a Trello card can be quite free-form, we’ve had to come up with several conventions to ensure we’re able to capture the data we need to build the reports I’ve outlined above.

1. Story points – Despite our move to a Kanban process, we’ve still found that providing estimates and tracking velocity is valuable for planning. For tracking story size, we use the Scrum for Trello extension for Google Chrome. This extension simply adds the story size to the card title in parenthesis, with some niceties around rendering the size as an icon on the card. Example: “(3) Add envelope icon to support link on Email error dialog – [Email Manager]”

2. Feature Group – Each card is tagged with a feature group to enable us to track where resources are being allocated. The convention for this is to add the feature group name in brackets to the card title. Example: “Add envelope icon to support link on Email error dialog – [Email Manager]”

3. Deployment Date – Once a set of features is deployed, they end up in a lane with the title “Deployed MM/DD”. Example: “Deployed 12/17″

4. Feature/Defect Type – We use Trello’s label feature to track the type of each card: Product Feature, P1-P3 Defect, Infrastructure, etc.

With these conventions in place, we are able to start pulling data from Trello via the API. We have built a simple reporting dashboard using Express.js, Node.js, and MongoDB. The Node.js application polls Trello on an hourly basis to collect any new cards, or synchronize data for existing cards. The key API calls we leverage are:

GET /1/boards/[board_id] – Returns the cards on the selected board

GET /1/boards/[board_id]/members – Returns the members (users) associated with the board

GET /1/boards/[board_id]/lists – Returns the lists (lanes) on the board

GET /1/cards/[card id or shortlink]/actions – Returns the history of actions taken on a card. We add the updateCard:idList filter which provides a record of how and when a card moved between lists. This data is extremely useful for determining cycle time.

Trello, with the addition of a few standard conventions for its use, and a minor amount of reporting code can be an extremely effective tool for Kanban. Do you use a Kanban software development process? Do you have a favorite tool or report? I’d love to hear about it in the comments!