Hey folks!
It’s my recently-promised article about Trello, the super cool, lightweight tool that looks and acts like a scrum board! I’ve been “using” Trello for a long time, but I recently started to re-vamp all my existing cards, trying to use the tool in a way that’s both less intrusive and more productive. This impulse was actually inspired by a recent push at work to adopt Agile methodologies, although we use JIRA for our needs. Of course, a big component of Agile is working with a team, which is not something I do on my personal projects (though I’m open to it!). That doesn’t stop me from taking advantage of some of the same issue/feature tracking principles, however. First, I think it’s crucial that anyone considering adding Trello to their workflow consider what problems they are trying to solve.
For myself, there were a few issues. I use Trello to track my planned features and progress on my Elder Scrolls Tabletop application (UESRPG CharGen). Since my playgroup actively uses this application, bugs are often found and needed features identified mid-session. However, I couldn’t tell you how many times I would say, “I need to implement X” and then forget all about it. Trello helps with that by housing my intended feature information, which I can keep in a backlog for later planning. If the feature is pressing, or the bug is debilitating, I have the ability to characterize it as such and begin work on it immediately, possibly shifting other items out of the way first. This is one of the most desirable features of Agile: being able to characterize and respond to issues/feature requests as they come up, even if they require one to change the development plan in-flight. As an individual, I can benefit from this without needing a team to tell me how many points I’m getting!
Beyond that, I found I would often have trouble anticipating the scope of the changes necessary. With my new Trello strategy, part of fleshing out new cards is filling in necessary work to complete. This forces me to really think about how to fit the changes into my existing structure (and I’m further aided by my use of MVC, which I wrote about here). Let’s delve into that a little deeper. When I write a new feature card, it contains some high-level title, for example, “The UESRPG CG shall handle character races, including starting stat values.” This statement is made using only in-game terms defined by the Core Rulebook, so anybody who is familiar with the game will have an idea of what this feature should deal with.
Within the card, we can add things like checklists, links, expanded descriptions, comments, and more! I like to start with a checklist of distinct items that are required to implement the feature. These don’t have to be high level, or even particularly detailed, but should touch upon the whole range of changes necessary. The card above has only three items for now: “Existing Character migration,” “Design/implement Race model,” and “Integrate Race model with Character model (especially WRT Characteristic values)”. This summarizes all the components of the app that will be touched according to my understanding at card creation time.
Then, I duplicate that checklist and convert each item to its own card. These cards become the subtasks of the feature, and they get their own label color to indicate that. For good measure, I make bidirectional links between the feature card and each of its subtasks. As the subtask cards are moved to the “Done” deck, I can click the link to the parent card and check off that item in the checklist. It’s a little more clicking than one might need to do with a tool like JIRA, but Trello is free, so I’m not allowed to complain!
Of course, while I use this tool in a solo capacity, it has a ton of potential for team use. It emulates a scrum board, so just like in a daily standup meeting, everyone on the team has a nice overview of the work in progress on various parts of the project. This high level of visibility is great for collaboration, because team members can see where others might need help, where features are being held up, and so on. It can be very helpful from a management perspective to see everything laid out in such a way and anticipate which items might be blocking others. A very clear flow of the necessary order of work items can emerge, which should be a goal for any good team organizer.
The final benefit I want to discuss comes not from Trello itself, but from the workflow and the mindset I’ve adopted here. I think it’s incredibly valuable to think in these bite-sized chunks, and to try and form a clear idea of changes to the system before writing any code. My migration to MVC has taught me that good architecture doesn’t just happen; it takes careful consideration. By using Trello to map out these future features, I feel that I have started to reveal necessary architecture changes to be made in the future. By thinking about all of these chunks in one space, I can anticipate and avoid potential structural pitfalls, thus avoiding the need to undergo massive restructuring efforts ever again (Andrew wrote, incredibly optimistically)! It has been quite a valuable exercise, to say the least. I hope you will find my exploration of Trello useful in determining your own workflow.
Do you use Trello? Some other free tool? I would love to discuss your workflows/suggestions here. As always, I can be reached by email at me@andrewdys.art.
Cheers! Andrew
Comments