Making project management a breeze Using Trello and Kanban

How we manage projects

For most projects of a certain size we need to be able to manage the work to be done as well as allow the client and all of us in Offroadcode to be kept informed of the state of the project.

The system we use is a form of Agile project management called “Kanban”. Everyone’s version of Agile changes between teams so this document is a quick guide to how we do it.

This is a guide, we might deviate from the below a little depending on the project at hand but one the whole if you understand the following then you should be able to use any of our Kanban boards and know what is going on and how to engage with them.

You will be able to see what state all the work is in, what to work on next, what others are working on, what items are blocked and in need of attention etc. so grab a brew and give this 10 minutes to sink in.

Kanban in a nutshell

Jobs are broken down into small enough chunks that they can be done within 2 days maximum but ideally they should represent smaller unit of work.

Each chunk gets created into a card which lives on our Trello board (see trello.com). A board is made up of a number of lists laid out side by side.

The jobs get added to the left of the board and our mission is to move them all over to the right hand side of the board. In between are a number of other lists the cards have to pass through which all mark a stage of the cards work life cycle (“todo”, “doing”, “testing”, “done” for instance).

Types of card

As stated each card should represent a unit of work that is no bigger than 2 days worth of effort. If it is bigger than that then it should be broken down into multiple smaller cards. Sometimes though we have a need for different cards so here are all the types that we currently allow for:

  • Standard card – a unit of work that’s estimated to be less than 2 days worth of effort to complete
  • Mega card (Normally has MEGA in the card title)– a card that holds an idea for a bigger project, probably more than 2 days worth but we’ve not had chance to dig into it yet and break it down however we do need somewhere to save the idea so this is where we put it. These cards often get broken up into smaller cards and the original mega card may even get deleted its work having been done.
  • Express card (Orange label) – a card that can break all the rules, these cards get looked at straight away. They are saved for super urgent fixes or very pressing deadlines (think a credit card fee change which for legal reasons needs to be done asap or the client faces a fine). They can mess everything up so should be a very rare event.
  • Blocked card (Red label) – A blocked card is any card that can’t be moved forward for some reason. This is shown by adding a red label to the card. Additionally a comment should be added stating why the card is blocked, what needs to happen to unblock it and a due date to re-check if we are awaiting something. Blocked cards are bad and if you see one you should jump on it to see if there is anything you can do to un-stick it.

Card etiquette

Cards at a minimum should have a good description - in the description field, a clear unique and short title. New cards should always be added to the bottom of the backlog list and only moved around on that list by a Project Manager until it’s on a sprint.

To keep the boards running smoothly we need to all play by some simple rules:

  • Name drop other users (by typing “@pete”) on a card only if that person's attention is needed.
  • Try not to name drop just to look like something is happening, we leave that for those folks who like to cc everyone within the company in all emails. We leave that sort of thing to other companies, not here.
  • Learn how to use the filters, they are awesome, learn how to use them, they are dead easy just click the filter icon and have a play around. You can filter by name, label, etc. very handy.
  • If you are asked a question on a card via a name drop then answer it as soon as you can, it could be blocking someone. Ideally check in twice a day and see if you’ve been name dropped by someone. You can do this by just checking the notifications panel on the right of the Trello board or by using the Filters.
  • Update a card if you are starting work on it so we know at least someone is working on it.
  • Assign yourself to a card if you are working on it, this avoids two of you doing the same card at the same time.
  • Assign others to a card only if they are required, see the rule about excessive name dropping above.
  • Fill in the description of the card with some context/understand of what the card is about and what is it trying to solve and why. Always include where the request for the card came from “@Reeva raised this on the conference call on 14th May:” so we know who is asking for what otherwise we will assume whoever opened the card requested it (this saves Olympic having to name drop themselves in the description).
  • In the description or comments always indicate what the next action is that is needed to move the card forward once you are done with your part of the work. Ie “Added filtering, needs an new API method called GetBoardBasis creating that will return all the available board basis in this format…” That is actionable, that requires no more questions, that can be done and handed back with the minimum of management need.
  • Include any information on how to test any work you have done for speed. If you’ve tested it yourself then take screenshots of your mod doing what it should so we know how to recreate.

Checklists are your friends

MEGA cards can quickly be fleshed out with checklists. You can add multiple checklists (did you know you can rename a check list? Just click on the checklists title to edit it). Check list items can be converted to cards as a way to break up a MEGA card into work that actually needs doing which is a great way to make a big card seem more manageable by breaking it into smaller ones.

Checklist rules of thumb:

  • If you know who is needed to do a check list item append their name to the end using the “@pete” style.
  • If you are unsure if an item is needed but want to document it anyway then add a “?” at the end of it and again name drop who is best to confirm/reject the item. If you see an item on a card that has a question mark assume it needs a follow up and ideally follow it up! A name dropped comment on the card should be enough “@pete as per the check list item above do you know if X got back to you and if so is it possible to do Y?”
  • List items can be prioritised by dragging and dropping them on the list. Normally items are listed in the order they should be done so start working on items at the top of the list first.
  • Only tick off an item if it is complete and ready to release.
  • If you are working on an item write a comment saying so.

Meet the lists

Lists are the most likely thing to change from project to project. As a result we might have issue a client with a custom set of lists with names that differ from the below or with more or less columns. However they should look something like this (appears from left to right on the board):

  • “Backlog” – The cards we would “like” to do at some point in the future. This could include MEGA cards and cards that are not yet fleshed out. You shouldn’t work on these cards but you can add to them.
  • “Next Sprint” – Work to do at the next sprint (a sprint is a set length of time that we have to work on cards, either a week or two weeks dependant on the client).
  • “This Sprint” – Work to be done this sprint
  • “Doing” – Cards actually being worked on right now, every card should be assigned to someone if it is in this list.
  • “Testing” – Work has been done and is now in the testing phase. If it fails testing it should be moved back to the “This Sprint” list with a comment explaining the issue and assigned back to the last developer who moved it to “Testing”.
  • “Ready for release” – cards that are tested and good to go
  • “Released” – cards that are out in the wild, work complete. We might have multiple release lists with the date of the release so we can go back to any cards that we find issues on. As a guide we keep the last 3 releases on the board for reference.

There may be additional columns depending on the complexity of the project. For instance if you have a staging site we might have a “Ready for staging” and “On staging” list so the client can easily know when cards are ready for testing, if its “On staging” then they should be able to test it.

Never let a card get stale!

If you have worked on a card then add a comment to it so we know what you’ve done, this keeps everyone in the loop that “stuff is being done” as well as “how much stuff is still to do”.

When updating a card make sure your comments add some value or knowledge, we don’t want comments for a sake but ones that you yourself would like to read if you had to pick a card up halfway through (imagine you go off sick, is there enough info in the card for someone to pick it up and complete it).

Comment on what the next action is to move this card forward and where someone might need to look to do that.

Source Code (aka Kiln) Commit messages

If you include a Trello card url in your commit message then Trello will automatically include that message and link to the commit in Kiln to the card. That’s pretty magic, make sure you do that. But remember that a commit message might not give a good indication of how much work is still to do so make sure you give a summary of your commits with a human friendly comment on the card directly if needed. I’ve seen many cards in the past with 10’s of commit messages but I’m still none the wiser as to how far towards “done” the card is. Remember checklists are your friend.

Who moves the cards?

Anyone with access to the boards can add cards to the backlog. Because a card is on the backlog doesn’t mean it will get done, it’s just a holding pet for ideas, bugs, features.

Project Managers (internally to Offroadcode and externally at the client) agree which cards from the backlog go on to the “Next Sprint” column.

This is done before each sprint and normally added to throughout the course of the sprint. Cards should be prioritised with the most important being at the top of the list.

At the start of a sprint all the existing cards on the “Next Sprint” column are moved to the “This Sprint” column at the start of a sprint. Any cards still on the “This Sprint” column should appear at the top of the list as they still need doing. Only PM’s should be moving cards onto a sprint.

Designers and developers can then start taking on cards from the “This Sprint” list and moving them to the “Doing” column (and assigning themselves to the card). Cards are prioritised with the most important being at the top of the list, so you should pick them from the top down.

Remembering the priority of the cards developers should take the highest card on the list that they think they can do. It may take several developers to complete a card (depending on skill set), assign the next logical person to the card.

Once a card is done it is moved onto the “Testing” column, this is normally where any internal testing can be done. Ideally another developer tests the modification so a second set of eyes has been on it. Any card in the testing column should be testable by anyone else but if you need someone specific to look at it then assign them to the card.

Once testing complete the card is moved to “Ready to deploy” which means it can go live. The tester moves this card and is effectively signing that card off. Again if you tested the card include screenshots so we can see it “working” as it should.

At some point a release will be scheduled and will be pushed up to live. Whoever does the release should recheck each of the cards (this is why the “how to test” comment on the card is so important) to sanity check it has gone up and then moves each card to the “Released” column.

Once again your column names may vary but the general flow and layout should follow the above.

What I really appreciate is how easy it is to communicate with Offroadcode and how organized they are.

I love being able to see exactly where my project is, what’s been done in the past and what is coming up next.

Amber Strawn, Chief Marketing Officer Brambleberry Soap

Hi, I'm James

Hi, I'm James

How can we help?

From Umbraco development (we won an award for that 👍) to design and development or giving you some advice, whether technical or if that hat really goes with those shoes - drop us a line below and we'll be in touch.