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.
Our software libraries allow you to
| Convert PDF files to HTML |
| Use PDF Forms in a web browser |
| Convert PDF Documents to an image |
| Work with PDF Documents in Java |
| Read and write HEIC and other Image formats in Java |
Also seriously look at the Chrome add-in ‘Plus for Trello’. It adds time tracking and burndown charts.
Hi Leon,
Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time, de-focussed our colleagues and interrupted their workflows). Because of this we developed a SaaS tool to “automate” the daily standup meetings – with just a single email.
Ajie
Thanks for the suggestion Ajie, good luck with it. I like the concept, it effectively turns what would be a synchronous meeting into an asynchronous one which removes a lot of the cons of daily meetings.
It actually looks like something that could be implemented using Trello (albeit not as automated), for example you could create a Trello board with a list for each developer. At the end of the day each developer could add their list of accomplishments to the list and then check back again in the morning to see what everyone else got up to.
Question for you Leon. We use five priority levels that we have defined as custom fields for our cards: 1 is trivial, 5 is critical. Do you also assign priority per-card, and if so, how does that work with your Wishlist, Future, and Soon lists? It seems to me like having them both would be redundant and confusing. What are your thoughts?
I don’t think there’s any one-size-fits-all approach. My personal view is that we should try things out to see what works best for us and then refine it over time. I think a lot depends on the size of the team, the size of the backlog and how granular the items are. Some people argue against having a backlog at all (e.g. Basecamp), and others argue for more elaborate styles of organisation.
I use a similar looking Trello board to organise my own ideas/tasks. I find the number of columns doesn’t matter so much as ultimately it’s all part of the same list of todos. What’s most important to me is that I can see everything that’s on a list without having to scroll it. The priorities are all relative anyway. If a task is added with high priority then by definition all the lower priority tasks are pushed back, just as would happen when jumping into a queue.
I think having the priority stored in the card itself would add an unnecessary step to change the value when moving it between lists.
On my personal board I use labels to indicate how much time a task will take. Green for <1 day, yellow for a day or two, orange for a few days, and red for over a week. I find that very useful when organising my day/week.
This approach does need regular maintenance to keep the backlog relevant and make sure that technical debt is being paid back.