Trello in Software Development—How to Manage Complex Projects

Trello

Trello, a simple yet efficient project management tool, can be a handy asset in software development. But it can also turn into a nerve-racking nuisance when misconfigured, hindering project development instead of facilitating its delivery. The trick lies in the initial workflow setup. A well-defined set of workflow rules will tame the beast, even in complex projects. I’ll show you how.

Default Trello Dashboard and Workflow

NOTE: You can skip this paragraph if you’re familiar with Trello.

To begin working on a new project in Trello, you have to create a new board with the name of your project. That board is your workspace. You fill it with named lists (e.g., To-Do, In Progress, Done—basic Kanban board for project management) where your cards (tasks) will be stored.

Each task can be customized (due dates, persons responsible for delivery, attachments, labels) to further improve organization. The workflow in this setup is simple: upon completion of a task from the To-Do list, you can move it to the Done list, for example.

 

Trello in software development - default board
Trello Default Board

Trello in Action—Building a Robust Symfony 4 Web App

To show you how Trello can turn from a handy tool into an untamed beast, let’s take a look at a project we used it in.

L’Autre Chili is a service selling tours from France to South America (Chile, Argentina). The owner, Sevan Hagopian, after experimenting with various WordPress templates and online website generators, couldn’t find a solution that would meet his business needs.

Contacting Polcode was his third attempt at building his website. Equipped with specific guidelines as to the design of his site, Sevan needed a custom website that would . Sevan approached us with specific guidelines as to the design.

We split the development process into three parts:

  • Stage 1—Designing and Front-end Coding
  • Stage 2—Back-end Coding, Front-end and Back-end Integration, and Setting Up the Blog as MVP (Minimum Viable Product)
  • Stage 3 (Work Still in Progress)—Designing and Coding the Blog

The Good Trello

When we started working on the first stage of the project, we created two separate lists in Trello: Design + Front-end, and then Front-end + Back-end, where we were adding specific cards. After completion of each card, it was moved into a collective list: Done.

This simple setup worked like a charm during the first stage when we worked together with the client polishing up the design.

The Bad Trello

Problems began when we moved to the second stage of the development process, where the tasks and steps necessary to their completion grew in complexity. With the current setup, it became difficult to recognize which tasks were in progress and which ones were a priority. Also, searching for tasks included in the numerous PDF files attached to the lists was burdensome and time-consuming.

Trello in software development - project board

It became obvious that, to move forward with the project, we had to introduce some serious changes to the workflow we were using in Trello. After discussing the matter with the client, we decided to do away with the initial workflow setup and move to Kanban with our specific ruleset.

Introducing Modifications to Trello Workflow

Switching to classic Kanban entailed a complete reorganization of the workflow. What was especially important was to establish new rules.

The New Set of Workflow Rules

  • One person assigned to one card.
  • Every list visible to all users.
  • Trello Janitor—a person responsible for managing cards (labeling and assigning them to users).
  • After verifying if a task from a card has been completed, the Trello Janitor moves that card to an appropriate list.
  • If cards created by the client require a broader explanation, the client has to attach PDF files with visual examples and an in-depth description.
  • When the client creates a card, he doesn’t have to add labels or assign users—this should be done by the Trello Janitor.
  • One PDF file is treated as a single card, and all the tasks included within have to be moved to the checklist.
  • A person responsible for a task has to create a To-Do checklist based on that PDF.
  • Every element on the checklist should be the smallest possible task to do.
  • The tasks don’t have deadlines—a person responsible for a task individually assigns priority level and moves the task from the Backlog to the To-Do list.
  • If the client considers a certain task a priority and its status has been confirmed with the devs, the task is labeled red and has the highest priority in the Backlog.
  • Any reported errors have to be described in detail (system environment, browser, circumstances, and attached PDF files with screenshots).

Project Communication

Trello remains the main channel for communication and arrangements. Other forms of communication are also allowed, but all project arrangements have to be added to Trello. This facilitates organization and ensures that everything is included in the project.

To maintain communication flow and transparency, we create a weekly backup copy of the board. It helps us go back to a working state of the project from a particular day. The board can be later recreated with a special Trello tool.

Managing Projects: Board Lists in Agile with Kanban Approach

To meet project needs, we decided to incorporate the following lists into the Trello board.

Resources & Communication—team availability, project updates (dates of major project events described), and links to servers.

Icebag—elements which were taken out of the Backlog but will be restored in the next stage of the project.

Backlog—here the client adds new tasks (cards) along with PDFs. When a discussion regarding details of a specific task ends, the Trello Janitor labels the card, assigns responsible users, and moves the card to the To-Do list.

To-Do—tasks with the highest priority. Because the devs had a high degree of flexibility in this project and there were many scope changes, we avoided strict due dates.

To Verify—a preview list for the client, containing the tasks ready for verification.

Done—verified and deployed tasks.

Room for Further Improvement (Optional)—occasionally a few cards end up here for further discussion. If the discussion results in the introduction of specific changes, the tasks go back to Backlog with a new checklist.

With that setup, we managed to tame Trello, and the main part of the L’Autre Chili project was completed successfully. The client was very enthusiastic about the results and our cooperation.

Project managed in Trello was a success
As a thank you gift, each developer on the team got a bottle of French wine 🙂

Keep Trello on a Leash and It’ll Deliver

To utilize Trello’s potential in software development it’s important to properly assess project needs and requirements. For small projects and small dev teams, the default Trello setup will be a convenient and efficient solution. However, complex projects require specific workflow rules put into place at the very start of the project. The role of Trello Janitor is invaluable here as well, as they will ensure all rules are followed and any mistakes are fixed whenever necessary.

 

Polcode is an international full-cycle software house with over 1,300 completed projects. Propelled by passion and ambition, we’ve coded for over 800 businesses across the globe. If you’d like to talk in detail about your IT project, contact us. We’ll be happy to help you get your idea off the ground.

Let’s Talk About Your Project!

Have an exciting project in mind? Or maybe something in your current setup doesn’t work?
Don’t worry, we’ll fix it. Let’s get in touch!

 

accept



Our Privacy Policy has been updated in line with the new General Data Protection Regulation(GDPR)