We are big fans of Trello at IDRSolutions and have several boards that we use for different purposes. One of the ways that we use Trello is to manage the release cycle (or sprint, for you agile folks) of our two products, where each product has its own Trello board.
If you are a user of our products (we produce a Java PDF Library and a PDF to HTML5/SVG Conversion Tool) and are interested in knowing how we manage product releases, or if you have an interest in Trello/Agile/Scrum and are looking for some ideas for how Trello can be used to help manage your Agile project, then this article will likely be of interest to you.
If you are unfamiliar with Trello, then I highly recommend checking it out. The product is free to use and also integrates with Fogbugz. Essentially, with Trello, you can create boards inside your web browser (there are also mobile/tablet apps). Boards contain lists that themselves contain cards. It is the digital equivalent of a whiteboard separated into columns with post-it notes stuck in the columns. You can share and allow editing of boards by colleagues. Cards can be moved between lists, have members, attachments, a due date, comments, checklists and more.
The software development methodology that we follow at IDRSolutions is based on but does not strictly follow Agile (so I recommend this article be used for ideas and not treated as a tutorial). Our sprint length is 1 month, and we meet once a week to discuss progress and talk through any items that have been raised needing a joint discussion. At the end of the sprint, we review the sprint, complete a release checklist, decide what should be focused on in the next sprint, and reorganise our backlog.
Here’s how that translates onto Trello:
The Backlog:
We separate our backlog into three lists. This is to allow us to make the best of the available space in Trello – with three lists we can see the entire backlog at the same time, without having to scroll the list up or down.
Backlog P3 (Wishlist):
This list is for priority 3 items (the lowest priority). It allows us to keep track of ideas that we have that we would be nice to do at some point in the future, but that we know are unlikely to be done any time soon.
Backlog P2 (Future):
This list is for priority 2 items (the middle priority). It allows us to keep track of our long-term goals and any ideas that we have that would be beneficial to complete in the not too distant future. The hope is that items on the P2 board will eventually make it onto the P1 list as space becomes available.
Backlog P1 (Soon):
This list is for priority 1 items (the highest priority). These are the items that are most important to us that we would like to complete in the near future. This is the list that we pick items from when we decide what we should be working on in the next release. As the length of this list reduces, we move items along from the P2 and P3 lists.
The Current Sprint:
Each sprint/release, we create a list to keep track of what we intend to complete this cycle. This allows us to keep track of progress in our weekly meetings and make adjustments if necessary. Each card is assigned a developer which means that they are accountable for that item.
Meetings/Scrum:
Here is one place where we do not strictly follow the agile methodology. Daily stand-up meetings for us are not practical or constructive. (Partially due to the team being distributed remotely and also due to well-defined roles allowing fairly isolated code changes.) Instead, we have one meeting (per product) per week to discuss progress. We split this into two lists. The following lists allow us to define a specific agenda for the meeting, helping us to stay on topic and to make sure the meeting is useful.
Items to discuss:
During the week, if there are any items that we wish to raise to discuss as a team, we add them to the to items to discuss list. The person that added the item will attach themselves to the card, assuming ownership of the item. After discussion, cards are either resolved and get removed from the board or moved are removed to the last list:
Actions:
Sometimes, an item to discuss becomes an action. This occurs usually when an item needs more research, or when we want to come back to the item in the next meeting to follow up on the item if a decision was made in the discussion. Again, each card has a member who is responsible for the action.
The Release Checklist:
Lastly, at the end of a sprint we complete the release checklist (which is a card on our current release list). This checklist contains tasks to complete in order to roll the latest release out, for example adjusting milestones in our bug tracker, putting release notes on our website and updating our RSS feed.
I hope that you have found this article useful or interesting. If you have any comments or questions, please feel free to leave a comment below.