Task management (via Kanban)

Building Acebook involved many small steps, each of those steps (aka tasks) were dealt with via a Kanban board. A Kanban board is a task management system, a number of columns (6 in our case) are appointed separate stages of completion for those tasks, those stages being;

1. Unestimated
2. Todo
3. In Progress
4. Blocked
5. In Review
6. In Production

Each separate step (aka task... or 'card'), is firstly applied to;

Unestimated

This is where User Stories, Ideas and the many seperate things we need to do are added, by all of us. Being a good tool to facilitate the Kanban process, we selected the 'Trello' app, for its many useful features and good UI. At this stage the 'cards' are not appointed to anyone, and are not estimated. It is simply a backlog storage of tasks... however we need to do some work so... when you are ready to start work, have written out the user stories, ideas and features that you would like to implement we start selecting cards.

To Do

Ideally the tasks here will be independently actionable, and ordered by priority. Here we estimate the required effort to complete the tasks, being pragmatic we focused on a simple rate of perceived effort (RPE) of low, medium and high over a more traditional numbered RPE score, one of which being a fibonacci like 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 rating... i feel that is excessive planning and time is better spent working than deciding an illusive, often inaccurate and opinion based number, it'd also stop people from taking those harder challenges. A team may select what they want to complete in a sprint by picking up a number of items from the backlog, clarifying the requirements, breaking down user stories into smaller parts and tasks that can be completed in half a day or less. At this stage all tasks are broken into small and independent steps, so that team members can work independently and are not held up by any bottle neck tasks (if there were, we would perform a scrum and all work on the critical path to get it completed asap).

Quite often a 'Sprint' can be carried out, we had two during this project, where we selected a number of those selected options from the todo list to complete in a specified time. Normally a sprint will involve the completion of a specific feature in a specific timeframe, such as two weeks. At its completion a new feature is picked up and again work commences in a new sprint, or some loose ends and smaller tasks can be completed before a new feature is decided upon.

In Progress

One task per person/pair. One task per person/pair. One task per person/pair.

As an individual/pair this is your home plate, you are safe here, this is what you are working on. You have one task here (selected from the todo list - which is communal for all), not more. This is to ensure other team members know what your working on, with Trello you would apply your name to the task at this stage, open up a branch on i.e. github and get coding (TDD'd of course). Once the code has been written, tests are passing you are happy with the additions, you add/commit/push the branch and create a pull request to the master from the branch you were working on... and move the card along on its path to completion, onto the 'in review' column. However if you get stuck keep your name on it, and shift the card over to 'Blocked'...

Blocked

This is where tasks that you are stuck on go, leave your name on it... and a helpful person will come along and help once they finish their ticket, before they start on a new todo if you are lucky, if not it is your responsibility to remind people that you/your task is blocked and that you need help completing it - which may facilitate as a reminder to those blocking the ticket. Adding an alert / time on the block is important, to ensure that it is not forgotten!

In Review

A kind of tricky column... after completing a task (aka card) (and making a pull request to master). The card is moved to In Review by the person working on it. Trello has the feature of attaching a link to the Github pull request to it, thereby making it easier for the reviewer/s (two of the unassociated to task team members) to find this specific pull request. One at a time the reviewers will check the code, the first reviewer will comment in the card, the second reviewer will apply a merge if they are both happy - and then remove the members and move the card to 'in production'. If either of the reviewers are unhappy they will make comments and move the task back to the todo column - so the task owner can make the appropriate changes when they are next free to pick a task. It is good practice in our team when moving a task to the 'in review' column, to review another person's card (if there are any), so that we have a continual flow of reviews and tasks.

In Production

You are done. Remove your name from the card, forget about it, don't worry about it anymore. Your code passed the tests, your code has been peer reviewed and it has now been deployed. Ps. it's your responsibility to deploy it.. make sure it happens! This was the system we used to a fairly strict criteria, it seemed to work quite well for us as we all enjoyed the project and i think came away with a really great app!

The End