How We Use Trello to Manage Releases

If you are interested in how our team works collaboratively to build Cognito Forms every day, then this is the post for you. If you just want to learn about how to create amazing forms, check out our help topics and our blog.

A Bit of History

When we started working on Cognito Forms many moons ago, we were a small team of two, working part-time on proof of concepts with no customers and few expectations. As our core Cognito team grew from these humble beginnings to the dozen or so now working on the product, we quickly learned that our informal discussions and whiteboard drawings were not enough to keep us focused and on track.

Since our team has been developing custom web applications and web-based products for two decades, we have a lot of experience in software development methodologies and were quick to switch to a more refined LEAN approach. LEAN software development is embodied in the principles of eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building in integrity, and seeing the whole. We already had integrated teams including design, development, infrastructure, marketing, and other skillsets. We already had the self-discipline of engineers and designers used to planning out features from requirements through production, without the wasted overhead of dedicated project management. We already knew how to develop iteratively, with small releases designed to deliver results with a predictable cadence. We even had a good grasp on how to manage concurrent release cycles, in those cases where we needed to work on big new features while also iterating on the current production release for small features and bug fixes.

However, what we did not have was a great way to track ideas and visualize work in progress in order to be an effective team. We considered using Team Foundation Server, which we use for tracking the source code of the product, to track information using work items. We also considered using LeanKit, which we use to manage one of our other software products. Both of these products include a Kanban board, which is a system for placing “cards” on a board into groupings to visually track the status of tasks and ideas. TFS simply did not have a great user experience and was too hard to customize to adapt to our needs (sorry Microsoft). LeanKit was a good fit, but felt like overkill when we first started out. Also LeanKit lacks some of the “it makes me feel good to use it” characteristics we were focusing on delivering in Cognito Forms and did not support “public” boards, which we planned to use to engage our customers in the feature management process.

Trello, The Kanban Board for Normal Folks

As you can guess from the title, we decided to use Trello to provide the visual and knowledge tracking components in our LEAN methodology. Trello is essentially a collaborative Kanban board designed for normal people to track anything. As they state on their website, “Trello is the free, flexible, and visual way to organize anything with anyone.” They do not even use the cryptic word Kanban to describe the product, despite the fact that it was created by a famous software product and consulting organization similar to ours, Fog Creek Software, that ultimately developed the product based on their own experience and difficulties managing iterative software development projects.

In hindsight I believe we were drawn to selecting Trello primarily because its goals are so similar to ours—to provide powerful tools to collect and collaboratively manage information that are easy to understand, fun to use, and approachable by anyone for any purpose. We also have similar pricing—free forever for most features, without limiting the creativity of our customers.

Our Process

Before delving into how we use Trello to manage releases of Cognito Forms, I need to take a few moments to describe the set of problems we had to address as part of our software development process. We needed to:

1. Track and prioritize features that we may or may not implement in future releases.
2. Allow our customers to see the features we are working on and help us refine and prioritize these features with feedback.
3. Track and prioritize bugs (yes, we make mistakes).
4. Manage features, tasks and bugs associated with the iteration/release we are working on.
5. Support the quality assurance testing process prior to release.
6. Historically track all of the features and fixes included in each release.

We have two types of releases. The first, and most important to you, are our feature releases, which includes new product features. We target having one feature release every 1-2 months and had eight feature releases in 2014. The second, less glamorous but equally important, is the hotfix release, which contains bug fixes for problems that squeaked past our automated testing and quality assurance processes. We also use hotfixes for internal items that affect our management of the product but do not directly impact our customers (features for us, not you). We had 9 hotfix releases in 2014, or approximately one per feature release.

Managing Feature Releases

There are two components to managing feature releases. The first is determining what features we will work on next. The key here is we use a public Trello board, our Idea Board, to track all feature requests from our customers and ask for comments and up-votes on these features to help us understand and prioritize these features. Also, this public board allows our customers to visually see what we are working on and what features we have already released. When handling support or answering questions on Stack Exchange we frequently reference features on this board and encourage our customers to subscribe to cards (features) they are interested in so they can receive email notifications when updates occur.

When we start working on the next feature release, we start this process in Trello by creating a new release board. These release boards contain a standard set of release management lists, including In Progress, Failed Testing, Ready for Testing, Testing and Ready for Release. We start by copying the features from our Idea Board that we have just promoted to In Progress into the same lane on the release board. At this point we have a complete copy of the public features we plan to implement and a clean board for each iteration/release to work with (a good thing for LEAN development). We also name the release board for the set of big features planned for the release, such as our upcoming Localization & Zapier release:

These cards then let us track progress as they move between lists (lanes), who is working on them, comments and screenshots, requirements lists, etc. Many of the feature cards also include checklists of Test Cases that need to be verified during quality assurance testing, as well as Failed Testing checklists of problems that were found during testing. This use of checklists avoids the problem of creating hundreds or thousands of tiny cards or work items that require separate context and overwhelm everyone.

The general flow of cards is as follows:

Developers and designers work on stuff in In Progress (it is nice to come in to work and know exactly what you need to work on without being overwhelmed). As features, bugs, tasks, etc. are completed, they move from In Progress to Ready for Testing. However, just because they are ready to test does not mean that they have been deployed to our test environments. At this point, either our automated twice-daily builds or manual releases trigger the deployment process automatically in Team Foundation Server, which uses scripts leveraging Trello’s REST API to move cards automatically from Ready for Testing to Testing as soon as our test environments have been updated with the latest test build. Our quality assurance team then tests each feature and either kicks them back to Failed Testing or promotes them to Ready for Release. Once we have everything in Ready for Release we are ready to launch!

After each release, we move the In Progress features on our Idea Board into a new list indicating the features included in the release and the date of the release. Similarly, we move the Ready for Release list into a release archive board and rename the list to match the name of the list on the Idea Board so that our detailed internal release archive matches our lighter-weight public board. Here is a peek at our 2014 release archive:

Managing Hotfix Releases

Our other type of release, the Hotfix release, is a necessary part of any iterative, rapid release, development methodology. We do not strive to release these, but also do not neglect the very important and critical need to quickly respond to production issues. In some cases we proactively detect these issues ourselves via our error diagnostic system, but often issues are reported by customers through our support system, triaged, and then fixed as quickly as possible. We track these issues on our Production board:

This board adds a common element to any LEAN product development effort, the dreaded Backlog, which contains all of the items we have not had a chance to get to yet but plan to one day. In the case of the Production board, this list contains only bugs that exist in production right now. Obviously, if we feel comfortable leaving them unresolved, then we do not believe they significantly affect our users enough to fix right now. While the Production Backlog tracks only bugs, the corollary for features is our Idea Board, which essentially is one large backlog board that we periodically groom and prioritize with the help of our customers.

Similar to the feature release board, the Production board has lists to track work in progress and help us manage our release process. Once the bugs/tweaks we are working on have been promoted to Ready for Release, we deploy a hotfix to production and move the list of completed cards to our release archive board, naming the list Hotfix with the release date in parentheses, thus wiping the slate clean on the Production board in preparation for our next round of fixes.

Organizing with Color

Overall, we have enjoyed using Trello and incrementally adapting it to meet our needs for managing releases of Cognito Forms. We enjoy the subtle improvements the Trello team has added over the course of this year, including support for more card label colors, which we use to identify the part of the Cognito Forms that a feature or bug affects.

We use a consistent color-coded labeling strategy across all of our boards, which really helps as we move cards around, review impact, and assign cards to different team members based on area of expertise. As you can see from the examples, we also color code the boards themselves, with Blue for the Idea Board, Green for release tracking boards, and Red for the Production board.

Wrapping Things Up

One day we may outgrow Trello as a Kanban companion for our LEAN development process for Cognito Forms. In the meantime, we are enjoying the simplicity and understated power of the user experience and the ease of collaboration that it affords us each day. We hope that our customers get a similar sense of joy using Cognito Forms for both their professional and personal endeavors.

Since we are constantly working to refine our own internal processes, we would love to hear from you about your own experiences using tools like Trello to streamline and visualize your personal and professional processes.