My dev project management with Trello

Those who know me are aware that I'm an unconditional fan of Trello. I use it to manage my personal projects, my client projects, but also my moves, my trips, my gift ideas...

The problem is that Trello's strong point is also its biggest weakness: flexibility. Because after all, it's just a tool where you can create boards, lists, and cards while adding some media and/or assigning them to users.

Since Trello doesn't offer a specific framework for managing a development project, everyone goes with their own personal organization, more or less good.

I won't say that my organization is better than another, but it has the merit of existing, I've been evolving it for 5 years and so far I still haven't found the need to migrate to a more specific tool.

I'd like to note that Trello now handles the addition of multiple accounts, which allows separating a professional and personal account, for example.

Two boards

If you're not familiar with Trello, a board contains lists, it's the largest level of granularity in terms of organization. Generally, boards will follow the main themes and areas of expertise, as in the example of an association's Trello below.

But in larger companies, or for agencies for example, it's better to have boards on more specific themes like a particular project.

Personally, the method I recommend, especially for small agencies or freelancers like me, is to have one board per project as well as one sprint board per developer.

I know that many agencies choose to have a single board for the sprint of all developers while assigning cards, but I'm too fond of the "comfortable" side of the personal board.

I find that as a developer, it's an opportunity to have an overview that's easier to read than when our tasks are buried with those of everyone else, and it's also an opportunity to add personal lists for personal notes, resources, reminders, etc., which aren't necessarily linked to a single project.

The project board

The project board is the central point for managing a particular project, it will be useful to all collaborators who need to find the information they're looking for, but especially to the project manager (or scrum master) to have an overall view of the project.

Here's a non-exhaustive list of lists that can be found in a project board:

• The backlog of user stories and bug fixes
• The history of deployed user stories
• User feedback
• The list of project contacts (client and collaborators working on the project internally)
• The list of project resources (link to the GDrive of multimedia resources, PDF of project specifications, link to the pre-production version)
• The timeline of temporal milestones and deadlines
• A space for various notes
• ...

The ultimate goal of such an organization is to ensure that even a collaborator freshly arrived and assigned to a project can find everything they need to start working, while being autonomous.

And for a freelancer, this allows for a real separation of projects, which makes it easy to propose developments afterward, while having real traceability of what has been thought, proposed, and accomplished previously.

The personal board

Even though the personal board allows the scrum master to analyze the progress of a collaborator's sprint, that's not its primary function. Here we're rather talking about the developer's personal space, their den in which they must feel comfortable, and where the gaze of others shouldn't put pressure on them.

From my point of view, managing tasks by moving cards is above all a psychological reward, the graphic representation of duty accomplished which helps keep motivation even when carrying out small tasks with little technical added value.

That's why the developer must feel at home and have full control over their personal project management and be able to add their notes, resources, tips, etc., in addition to organizing their completed tasks.

I use the following lists for personal task management: TO-DO, DOING, DONE, and finally TESTED.

The lifecycle of a task goes like this: First, the task is added along with all the others in the backlog, then it's assigned to a developer and sent to their personal board, in the (TO-DO) list. Once the task is completed and tested, it will be pushed to production and will then be moved back to the general project board in the list of deployed changes.

What's even more practical is that by making sure to move the cards at the right time, it's possible to have a very precise idea of the time taken at each stage since Trello gives the exact date the card was moved!