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.
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.
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.
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.
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.
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)
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.
This blog post was originally published on Inside GOV.UK