Software development process that is transparent is essential for every team. Tasks and goals have to be clear both for developers and stakeholders. Everyone should know where the team is heading and what current priorities are. The good process saves a lot of time and alleviates pressure from the team. It also allows you to go back in time and see what and how has been done for a specific feature or a period.
No matter what Kanban-Based project management software you use you will have a concept of cards. Cards will be arranged by columns and moved by team members. Usually, you can add attachments to cards, add a description, comments, tasklist and many more. I will use Trello as an example tool throughout my writing because it’s free, powerful and available to everyone. Using Kanban the right way is crucial for organizing the work.
Every task has to have a card associated with it.
First of all, make sure that every task that team member is working on has a card associated with it. This card will be a container with all information related to the task — date started, date ended, time spent, current state, related cards, communication and many more. Creating a card for every task can quickly become repetitive, but it will pay off in the long term. Typically you will have a team member responsible for creating and managing the cards — a project manager.
Don’t worry about the number of cards growing unmanageable over time. Trello has powerful features like labels, filters, archiving and others that will allow you to quickly filter out cards you don’t need at the moment or find a specific card you need. Their full-text search is somewhat limited, or at least I don’t know how to make it work, but you can achieve most of the tasks you’d want to do with filtering.
You need to have meaningful stacks for card states.
Designing proper states for cards from the very beginning is essential. For example, you would typically have Icebox for cards that are not actionable yet, but you want to keep track of. That will usually be your biggest stack with a lot of out-of-date items that have to be cleaned up, but you don’t have time to do that. You’d want to have a backlog of things that are ready to be worked on, but they haven’t been assigned to anyone yet. You’d also want states like ‘In progress,’ ‘ready for review’ and ‘done’ which are pretty self-explanatory.
I usually recommend adding a few more states to have a little more information about a state. Since we do business and technical analysis, we have stacks for cards in that state. That way PM can quickly see what items are in analysis/discussion and for how long. We also have ‘deployed to staging’ state to see what stories are sitting on staging and ready to be deployed to production. Some of these states are not relevant for every type of the task, and we skip a stack or two in that case. Make sure to add stacks that suit your process, make sure there’s not too many of them. I’ve noticed that having more than 7-8 stacks makes the board much less useful because they don’t fit on one screen.
Create multiple boards for different management levels
One problem I typically see with organizing Kanban boards is that too much information is being put on a single board. In Trello you can use multiple boards, reference cards from other boards and even create meta boards that include cards from several boards at once. That allows you to have a lot of flexibility and have boards for a certain perspective.
For example, card stack setup I’ve been describing before is typically used on a sprint planning board. Cards that are in progress are expected to be finished within the sprint, and those that are in backlog will be worked on in upcoming sprints. But this board doesn’t allow you to see a bigger picture of where the project is heading or track bugs.
You would typically create a separate roadmap board where each card will represent a bigger feature, and you would track states of those big features separately, referencing cards from the sprint board. For bug tracking, you will have another board where your QA engineer will add bug reports, and bug state will also be tracked. Those cards can then be referenced on a sprint board to connect an actionable task for a developer with the bug report.
Adding relevant and vital information to cards makes them more valuable.
The concept of cards is a very robust way to organize all task-related information. If it’s a developer’s task, then she can add her own checklist to the card so that it’s clear to everyone how many steps left. You can (and should) add start and planned end dates and overall time spent to keep track of the effort. There are a lot of power-ups for Trello that allow you to map cards on a calendar so that you see how the work happens over time.
Collecting all task-related communication in one place is essential. If discussions related to the task happen in task comments, they will be easy to find and reference in the future, which becomes super valuable over time. You can attach Google documents, Github pull-requests, and designs from Figma and Invision to reference communication that happens elsewhere. For projects that take more than a few months to complete it becomes very important to be able to connect the dots and find why certain things were done or omitted.
Creating the process that is suitable for your team takes time. Feel free to experiment with different board setups and ask your team members what they would like to use. Make sure to clean up your boards and archive cards that are not relevant anymore. Update statuses as soon as they change, because a board that contains obsolete states is pretty much useless. Try to convey the idea of keeping communication in place to your team members — it never works from the very beginning, but people get used to this over time.
