Teams at GDS are free to pick the processes and tools that work for them. On the GOV.UK Publishing Platform, our Kanban process is supported by Trello. This is a follow-up to my blog post on How we use Kanban on the GOV.UK Publishing Platform team, and explains how we use Trello to support our Kanban process.
What is Trello?
Trello consists of boards, lists and cards. You can have as many lists as you want on a board, and as many cards as you want on a list. Cards contain all the information about the work to be done, and they are highly customisable with many different features such as checklists, commenting and attachments. A Trello board offers a great overview of your delivery because you can oversee multiple project stages all on one screen. It’s easy to add or edit lists and to move cards from one list to another.
How we use Trello
We use Trello both for long-term planning and to manage our day-to-day work. We like to keep things simple, so to avoid information overload we’ve separated our work out into 4 boards.
Planning board
The planning board is for work that’s yet to be prioritised.
Stories are proposed by someone in or outside of our team. Our story template helps people provide the right information. Periodically, our Tech Lead and Product Manager review proposed stories and triage them into other lists. If it’s something we’re not going to do they archive it.
Support work is for minor work requested by other teams or bugs identified by users. Mission work is for significant deliverables that will help deliver the GOV.UK goals. We try to strike a balance between long-term improvements and making sure the platform works for users now.
Stories that are next up for planning have been prioritised to be fully written, reviewed and estimated by the team at the next planning session. We usually have planning sessions every week, but we cancel these if there’s still too much work-in-progress.
Stories on the planning board are unlikely to be done any time in the next week. So we don’t put too much effort into writing, planning or breaking down stories until we think we’re going to have capacity to work on them. We minimise wasted effort by delaying delivery to the ‘last responsible moment’ - a key agile principle, meaning we don’t commit to decisions until we’ve investigated them as fully as possible.
Doing board
The doing board (or Kanban board) is for work that we’re doing now, or plan to start in the next week. This is the board the team reviews in daily standups, so it’s important that we keep it simple.
No story should enter this board until it’s ready to work on. That means:
- it has been prioritised by a product manager
- the problem that the story is trying to solve should be clearly understood by the team (the user need should be obvious)
- objective acceptance criteria should be written (checklists are great for these)
- the story should be estimated using story points (a number from 1 to 3 which indicates relative complexity)
- it should be properly labelled so we know what type of story it is (labels can be used as filters and help us generate useful statistics)
Individuals add themselves as members to cards that they’re working on. Some also follow lists to get email notifications when a card moves to a new stage. The list headings are pretty self-explanatory, but they’re also defined in the board readme.
Sometimes we have repeatable tasks - chores that need to be done every month or week. Using the Card Repeater Power-Up, these automatically appear at the top of the backlog when they need to be done.
Done board
When a card is archived, you can still find it via search and links. But we like to keep a more visual record of the work we’ve delivered. So at the end of every month, we move all done cards to the done board. There’s a list for each month, so it’s easy to browse historical work. Again, to avoid clutter, we don’t keep more than a month’s worth of done work on the doing board.
Long-Term Vision board
Our long-term vision board gives us a high-level view of work that’s planned, in progress or done. Each list represents 2 to 3 months of work and usually corresponds to a stage on the roadmap. Each stage contains one or more big stories (or ‘epics’). For example ‘Implement End to End tests’ is a big piece of work that takes months to deliver. So we’ve broken it down into smaller stories, such as ‘Audit End-to End-Tests’, and referenced them in the description. Checklists allow us to keep track of how many stories still need to be done.
Extending Trello
We love Trello because it gives us the flexibility to easily change our delivery process. We use the following Google Chrome plugins to help us optimise Trello:
- colour card titles for Trello (puts the label title in the label)
- kanban WIP for Trello (the bracketed number in the list title is the work-in-progress limit. If it’s met the list goes amber. If exceeded, the list goes red)
- projects for Trello (I use this plugin to explain why a card is blocked or what it is blocking)
- card numbers for Trello (useful for referring to cards quickly)
- slim lists for Trello (squeezes the whole board onto one screen)
Measuring performance
We use an unofficial Trello app called Corrello to measure useful statistics such as cycle time (the time spent working on a story), work-in-progress and velocity. Trello labels and Corrello’s customised reporting combined allow us to track how we’re performing for different types of stories. Putting story complexity estimations in brackets in the title also allows us to track progress by points rather than for each story individually.
Don’t let a tool dictate how you work
Many agile teams favour non-digital tools such as agile walls because of their flexibility. This flexibility is the same reason I love Trello.
At a recent retrospective the team identified that delayed product decisions were slowing down their progress. So we added a ‘product review’ stage to make it easier to visualise the Product Manager’s workload.
As it’s available online, it also doesn’t constrain us to all be working in the same place. Teams work better when they are colocated, but Trello makes it easy for people to work remotely some of the time.
Agile teams work best when they self-organise. Trello makes it easy for us to determine our own way of working - whether that’s Kanban, Scrum or something else entirely.
Alan is a senior delivery manager on GOV.UK. You can follow him on Twitter.
8 comments
Comment by Lucy Janes posted on
Was just setting up my Trello board when this popped into my inbox! Thank you: very useful.
Comment by Paul Cartee posted on
Great post, thorough and helpful. Thanks!
Comment by Rob Aldam posted on
Apologies for the late comment, as I've only just seen this.
How do you get round the security issues involved with using Trello? We've looked at using Trello on-team previously but no one has been prepared to tell us that we won't be held accountable if it's hacked.
Thanks
Rob
Comment by Alan Wright posted on
Hi Rob
We don't publish anything on Trello that we wouldn't normally have to release under an FOI request. If it gets hacked or somebody accidentally stumbles across the content then this won't pose a problem as the information can be made publicly available anyway.
Most official classification content is fine but we wouldn't publish anything which could have damaging consequences if lost or stolen.
Thanks!
Comment by Geof Harries posted on
So how do you manage the stuff you don't put into Trello? Where does that go?
Comment by Alan Wright posted on
Hi Geof.
All our work in progress for this team was tracked in Trello. Things that didn't relate to the team's goals were tracked elsewhere. The only exception was actions from retrospectives, which we kept on a separate board. In my new team, we're trialling putting everything on the Trello board and using filters to create views that stop it getting too cluttered.
Thanks
Comment by Adam Robertson posted on
Thank you! Have just started an agile project management role, and this has opened my eyes to a lot!
Comment by Alan Wright posted on
Glad you found it helpful Adam!