It’s been over a year since we reported on our development process with How We Use Trello. While we are constantly looking for ways to improve, become more efficient and transparent, our process has stood the test of time.

One improvement we have made has been to perform Discovery Workshops before we jump into development. By having a structured workshop we are able to to seed a project with higher quality user stories and help the client focus on their MVP.

We like to think we have just enough process and structure to be efficient at getting things done and maintaining transparent communication. This past year or so has really proven this to be true.

Production vs. Pre-Launch

The only true variation in our process among different projects is the distinction between if the project is in production or is in a pre-launch phase.

When a project is in pre-launch we have the Ready for Demo and Deployed to Demo queues before a card is accepted by the client and it moves into an accepted queue.

Once a project launches, we do several things to extend our process to manage a workflow with a couple more steps:

  1. branch from master and create a develop branch in the git repository
  2. create a new instance on Gondor to serve as the new production instance
  3. create a new list on the board called Ready for Production and rename the Accepted This Week and Accepted Last Week to Released This Week and Released Last Week, respectively

The workflow then changes to:

  1. master is deployed to the new Production instance
  2. develop is deployed to the Demo instance
  3. feature branches branch off of develop
  4. when ready for review and merge, the developer creates a pull request and moves the card over to Ready for Demo
  5. once the card is reviewed, merged to develop, and deployed to Demo, the card is moved to Deployed to Demo
  6. Once the card is accepted on Demo, it is moved to Ready for Production
  7. Once all cards are accepted that are on Demo, develop can be merged to master and then deployed to Production

This does create some possible blocking of a release if new pull requests are merging faster than the cards are able to be accepted on Demo, but what we have found is that natural batches occur and we will just hold up merging PRs until everything in Demo can be unblocked and accepted. This heightens the importance of clearing blocked cards on Demo.

Using Trello for Product Development

For sites where we are doing product management as well as the engineering, we have starting using a parallel board to manage the product planning. This is where we capture any ideas that are not in our current sprint. The development board is then focused just on current sprint.

ThoughtStreams' Boards
ThoughtStreams' Boards

Each month (we run monthly sprints, though we often deploy multiple times a day), we will curate a combination of major feature epics and enhancements from the planning board as well as any carry over items from the previous sprint that did not finish and establish a fresh development board for the new sprint.

Anything we decide to punt on that was on the development board goes back to the planning board.

By separating into two boards we keep a clean view of the current progress while allowing a switch to a longer term and someday / maybe view of the product whenever we like.

The planning board, unlike the development board, has less of a linear workflow and is designed more to map out features. It has an Ideas and Backlog list followed by lists for each major feature or epic.