Software project management is not as trivial as it may seem at first sight. Unlike other projects with tangible outcomes, software cannot be clearly specified up front and any monolithic waterfall approaches are doomed to fail. Agile methods have proven to be more suitable for software. What happens though if the team works remotely? How do you deal with the project board? How do you hold the standup meeting? Web based tools are the obvious answer. Hence we examined many of them and we concluded to Trello, Asana, and Targetprocess3 (Tp3) as the best choices. Key features were simplicity and not very steep learning curve, support for mobile devices, and of course a free plan for small teams (necessary for peace of mind in case you have chosen the wrong tool). Based on these criteria we selected Trello for the team. I’m also using Asana as a personal todo list, according to the suggestions of ‘Getting things done’ by D.Allen (details on Asana in a future post). Tp3 is used in an experimental mode in order to learn it (much more complicated and complete than the other two) and possibly use it in the future with a bigger team.
Having settled with Trello, we had to decide about the process and the lists to be used. Trello provides enough flexibility and does not promote a particular methodology. So after some projects, trial and error, some time of despair, we managed to find the structure that fit our needs. We found very useful advice in many articles around the web explaining how other teams are using Trello successfully[1],[2],[3]
We are using the following lists (columns):
STANDUP MEETING: Contains one card for each sprint. The Goals of the sprint are set here. Team members should add a comment daily explaining briefly ‘Y: what I completed yesterday’, ‘T: what I’m going to do today’, and ‘P: any problems I have’.Each answer should not exceed 2-3 lines and any additional details should be added to the respective cards. This process is an imitation of the real standup meeting and it is very important for remote teams which cannot meet physically, not even via skype because of geographical limitations, time difference, personal obligations, etc. At the end of each sprint we add a final retrospective comment.
IDEAS: Ideas or suggestions that need to be examined in order to become features or not.
FEATURES: The functional requirements of the system. Each feature is divided to a checklist of items (user stories) which can be implemented separately. As Trello does not provide links between features and user stories, we assign to each feature a ‘serial number’ using a hashtag (e.g. #002) which can be used in user stories, tags, or bugs as a reference to the feature.
TASKS: Non functional requirements of the system. Work to be done in order to support the functionality of the system.
BUGS: Errors, problems, malfunction identified during testing or reported by the clients. We use hashtags to indicate the status of the bug: #new, #accepted, #rejected, #solved.
BACKLOG: A list of the ‘user stories’ to be implemented. User stories are added here as they are identified and we don’t need a detailed analysis to find every possible user story.
SPRINT: User stories, tasks, and bugs to work on during the current sprint. These are selected at the initial meeting of the sprint and if possible team members are assigned. If all selected cards are implemented ahead of the sprint end date (actually this rarely happens), then we select more from the backlog, the task and the bug lists.
DOING: Cards we are currently working on. This list should contain a minimum number of cards, ideally one card per team member.
DONE: Cards of user stories and tasks which are completed. A card is assumed complete if all the checklist items are implemented and tested.
FIXED BUGS: Cards of bugs that are fixed and tested.
A sample board with our columns can be found here: https://trello.com/b/fylaH7r6/sample
We also use colour code to indicate a card’s type. This is very important when the card leaves the initial list and goes to sprint, doing, or done. The code appears on the following image:
Order of cards is significant and indicates the priority in which a card should be examined and processed. The order is rearranged during the retrospective at the end of each sprint.
We have tried this method for a team of 2-3 members on small projects of approximately 6-months duration and it worked perfectly. Now we apply it to long term projects and we expect to have the same amazing results. However, the larger number of features and tasks might be a trouble given Trello limitations.
