My Trello workflow – Web Performance and Site Speed Consultant

I’m a huge fan and proponent of working agile and the various schools of
thought around it: scrum; Kanban; MVP; product-led, iterative development;
releasing little, early, and often; you name it.

I recently shared
a public demo of the Trello board that I use
for development work—just one small aspect of running an agile project. This
post won’t teach you anything about running an agile project or team—you can
hire me for that—but it might help you set up a decent Kanban board
if you already know how to work agile.

You will probably want to have this Trello board open as you read this article,
because things will make a lot more sense if you can have a look around for
yourselves: trello.com/b/demo-project

Trello

Personally, I really like a physical Kanban board—using magnets and different
coloured index cards—but given that I work with distributed teams, and I
work from various locations, a physical board just doesn’t work. We had physical
boards at Sky, and they were great—10′
long, and perfect for standing around and discussing during stand-ups.

Because I can’t have a physical board, I use
Trello, which is an amazing, free,
online Kanban board produced by Fog Creek. If you
don’t already have a Trello account, you should definitely get
one.

The Columns

The most fundamental part of any Trello board is its columns. At Sky, we had
around 18 (yes, one-eight) columns on our board, but they worked—they all had a
place and a purpose. Sky’s board covered everything from design to DevOps,
engineering to acceptance testing, and everything in between.

My boards are typically a lot less extensive, with eight columns, but—as is the
agile way—I can scale them up or down depending on what comes my way. Whichever
way you look at it, it’s fairly safe to say that the standard To Do,
Doing, and Done columns aren’t up to the job.

To Do, Doing, Done

The traditional—and Trello’s default—column structure is a simple To Do,
Doing, and Done. This sums up the general sentiment of a
development project, but it’s a vast oversimplification of the process. There
are different definitions and states of done, for a start, and various
people have different jobs to do at different stages of a sprint. My
current setup has the following columns, which I will explain in more detail:

Product Backlog

The Product backlog is the product’s wishlist: This is the stuff that we
might want to build at some point. This can be seen as a dumping ground of ideas
and nice-to-haves, and the client is usually allowed to add and expand on things
in this column. It has nothing to do with the current sprint, but will be the
source of tasks for all future sprints.

Sufficiently mature products/projects might have their own Roadmap Trello
board elsewhere.

Sprint Backlog

The Sprint backlog is the stuff that the team has committed to building
in this current sprint. It is sourced from the cards in the Product
backlog and should amount to one sprint’s worth of one scrum’s work. The
cards in this column should be decided on and prioritised by the entire scrum:
clients/Product Owners should steer product and feature decisions, and the
development team would decide on a suitable workload. Priority would usually be
proposed by the Product Owner, but ultimately decided by the whole scrum.

Elaboration

A lot of the time, tasks might need investigating or discussing before you can
start working on them properly. For example, you might need to read up on
various different APIs before deciding which—if any—you might use for
development.

Featured case study: NHS

How I helped the NHS rapidly build a brand new product.

Read case study…

A good real life example would be the card I dealt with just today. We’re
working on a very rapidly-developed project for the NHS, and phase one came
together very quickly. I created a card called Performance improvements
in which I wanted to introduce
ImageOptim-CLI and
CSSO to our automated build process
(given the time-constraints of P1, we ran ImageOptim-CLI manually, and given
that the CSS only weighed 7.5KB when minified regularly, CSSO was of little use
to us anyway), but it was a task that had to be discussed: Was the time-cost of
integrating CSSO going to save us a substantial enough amount of bytes over the
wire? Could we run ImageOptim-CLI as a Git-hook? This was the elaboration phase
that this card went through before we decided to implement any work, if at all.

Anything in the elaboration column is typically an investigative or discussion
piece, and a lot of—if not most—cards will never need to pass through this
column.

Implementation

Implementation is just another word for Doing: we’re basically
just implementing any work we’ve decided to do. This could be getting content
from a client, designing a user-profile page, building out our architecture,
setting up live environments, anything.

Implementation should cover the bare minimum to get that task considered
complete: testing and approval are separate tasks to actually implementing the
feature.

Implementation Done

This is probably the one column that everyone’s board could use right away. No
matter what process you have already, this column is so useful.
Implementation done is basically a column for work that has been
completed by a designer or developer, but isn’t yet being reviewed, tested, or
put live. The work is done, but the whole task isn’t. This column serves a few
purposes.

Firstly, it allows a developer to do their immediate tasks and then move on to
the next thing without having to worry about getting a Product Owner’s nod of
approval, or a test engineer to scrutinise it, or having to roll a release and
put it live. It keeps productivity up by limiting the scope of ‘done’. They can
queue up tasks for a future release, or a whole round of acceptance testing.

The next thing it does is it allows the rest of the team to see what tasks are
dev-done and are available to be reviewed or tested—something might have been
built and is functionally complete, but no one has started reviewing that work
yet. Anything in Implementation done says ‘Hey, my developer thinks I’m
complete, so someone please feel free to come along and test me.’ This column
becomes the to do list for the next people on the process.

(User) Acceptance Testing

User acceptance testing (UAT) is when a client or Product Owner takes a
look at the task and either approves or disapproves it based on whatever
criteria you’re working toward. Anything that fails UAT would typically be moved
back into the Sprint backlog column until someone is available to amend
whatever was wrong with the work.