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 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:

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:

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:

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):

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.

Client quote

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

Want to chat about a project?

I'm proud of what the Offroadcode team have designed and built for our clients and the results their projects get and how they help their customers and visitors achieve their goals. 

Looking to talk about your project or want to hear more about what we can do help you? 

Send me an email or give me a call on +44 (0)1484 643078

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.