Trello is a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what's being worked on, who's working on what, and where something is in a process and presents itself a most common Kanban board principle realization.
The main goal of this principle is not to manage developer's time, but rather to give you visibility into what is happening in the project. This enables planning work, tracking progress, and retrospecting. In this guide we will talk about productivity system, which is based on ideas from Getting Things Done and Kanban.
Everything that everyone needs to remember must be logged to Trello. Only then team would be able trust it and developers and managers won’t have to run through five notebooks to make sure that have not forgotten anything. When an idea pops up, you need to be able to capture it. This must be as effortless as possible like it's realized in Trello.
-
Visualize team work. Everybody should always have a clear picture of what everyone is doing, how well it is going, what is blocking, and what have been already accomplished. Using boards and cards is a great way to visualize this information.
-
Minimize work in progress. Having a lot of things in progress generates waste. Developer has to constantly context switch, which makes feel overwhelmed and not very productive. This is another example when using a Kanban board shines: everybody knows how many cards are in the “in-progress” column. It is possible to set a limit of cards. So when you want to take on another task, you can see if there is room. And if there is none, you have to finish one of the started tasks, or push it back till later.
-
Dealing with stale tasks. We always tend to push back certain important but unpleasant tasks till later, so they can be on our task list for months. They have to be dealt with, and it is better to do it sooner than later. Others are not important. Developers subconsciously know it and that is why they never would be done. Trello has a nice feature called "Card Aging" that helps deal with this problem.
-
Backlog and sprint. All the tasks and notes which may be needed someday should be stored in a board called "backlog". "Sprint" idea came from Agile methodology and means, in other words, iteration with the list of goals at the end of it. Trello gives us possibility to make
-
Retrospect. Team should do weekly retrospectives during which go through all the completed tasks and label them with respective labels.
Each card during sprint should pass through the list of mandatory transactions: starting from idea in the Icebox, passing through clarifications from Product Owner, up to development and finishing this sprint at the production. Should admit, that responsibles may be switched between developers, testers and managers while this cycle. The wide list of the states may be looked like this:
- Backlog. Contains mostly ideas neither completed read-for-development cards.
- Icebox. Being process and ready to be done, cards in that list should be ordered by the importance.
- Needs Clarification is a helper state if clarifications from Owners is acceptable. It's ok to skip this step if everything is clear.
- Critical. Everything that should be done ASAP, means this card has a blocker / bug from staging or prod.
- Rejected. All useless ideas goes here.
- Sprint (date). The stack of tasks for the team for today.
- In Development. The best indicator to understand what's everybody doing now. Should be taken from To Do.
- Finished for Code Review. Must represent existing, working and tested code inside the ready-to-merge Pull Request. Goes here from In Development part.
- QA Test on Staging. Here comes testers, first baptism of fire for the new code. Should be processed by QA after first deploy to stage server.
- Deploy to Production. List of tasks, ready to be shown in real life.
- QA Test on Production. Last try to catch released bugs.
- Finised (date). Last step for accepted task. Provides retrospective for the sprint, shows was it successful or not.
So we exposed the states but how to decide which card would have the highest priority inside it? The concern is to place tickets inside list depending on its value for development. Tickets should should be moved out of the list only from head.
Here is the list of labels we prefer to use in our development using Trello: Bug, Feature, Blocker, Backend, Frontend, Communication, Others etc. Due to Trello makes us able to set more then one label, we can use some of them, if task requires few things to be done consequentially, i.e. set 'bug' + 'communication' + 'blocker' if you'll need more clarification from QA about it and 'notify Huston' about the seriousness of the problem. Let's discuss each of the label.
-
Bug: Should be set as a flag to the problem been found.
-
Feature: We set it to identify the request of implementation of something new.
-
Blocker: Identifies feature or bug as a highest priority thing to be done asap.
-
Low Priority: We skip other priorities to identify this one as an auxiliary tickets to be realized only if other priorities in sprint were accomplished.
-
Backend: identifies ticket as one which deals with backend mostly.
-
Frontend: this ticket would require to show your frontend skills too.
This is uncategorized type of labels which can be unique inside each board. For example we had tickets labeled as Communication which meant you'd have to clarify something with somebody. Usually those tickets had more then one assignee.
It's often a good idea to understand how things are going inside the sprint. Would we handle all stuff until it ends? Are our estimates correct? And in doing so, we come to the aid with Scrum for Trello: http://bit.ly/1kfsywP Crome extension. It adds estimates or record time-spent directly on Trello cards. Shows sums at the top of each list and the top right corner of each board. To use, simply open a Trello card and click the title of the card to edit it. There are buttons with Fibonacci numbers (1, 2, 3, 5, 8, ...etc.) to let you quickly add an estimate and time you spent on the task.