Unrecognized Escape Sequence

tldr

1. It can be helpful to separate a backlog into multiple sections, stratifying cards into different stages of refinement.

2. Cards start as raw, un-edited ideas and bugs in the first section, and proceed up to ready-to-code technical tasks in the last, with intermediate stages.

3. This makes it really easy to focus in sprint meetings on the goal at hand: moving cards from one section to the next by ‘refining’ them. This might be turning raw ideas into user stories, or turning user stories into estimated, prioritised technical tasks.

In the beginning…

One of the recent frustrations that our agile team has had is around the wooliness of our process concerning the backlog. As is fairly typical, we had a “Backlog” column on our Kanban board in which there was a mix of all kinds of stuff. Stuff like:

• Prioritised, estimated and ready-to-go-into-a-sprint technical tasks
• Early-stage, half-defined stories from the product owner
• Mixed-priority bugs
• IOU-style cards describing technical-debt
• Absolutely nonsensical, not even half-formed cards from various sources

Our existing process concerning the backlog involved a backlog grooming meeting each week (twice a sprint), during which cards in the backlog are cleaned-up, broken-down and given a rough estimation. You know, what we like to call “grooming”. We also have a release planning meeting once in a while, during which cards are selected from those in the backlog and moved into a column called “Release shortlist”. From here cards are selected to be worked on during our sprint planning meeting.

We also had several problems consistently coming up in sprint retrospectives which seemed to be related to this part of our process, the more serious of which were likely affecting performance and overall throughput of the team:

• Developers starting work on a cards, then realising more design / research / thought / external input was required to begin coding, so the card immediately becomes blocked.
• Long and dry sprint meetings with a lack of focus

As a quick aside, the latter of these is something that I’ve experienced in various jobs and seen how badly it can affect agile teams. The lack of focus leads to drawn-out, boring meetings. This leads to disengagement, which in turn leads to lower output, negativity during meetings, and exacerbates the initial problem. It is really important to engage with the fact that – by nature – coders want to be coding, not planning or discussing what to code, designing the best way to code, or testing code. As a result it is crucial to make it as easy as possible to do these other activities, so they still happen effectively.

To try and resolve these two problems, I formed a plan to attempt to clarify our process surrounding the backlog and our meetings related to it. It seemed a glaring inconsistency to me that we had several columns on our kanban board dedicated to the flow of cards within a sprint, but a single “Backlog” column for the entire phase of creation and refinement leading up to each sprint. To encourage a different way of thinking about the backlog, I’ve started to use the metaphor of an oil refinery for the work of processing cards in the backlog. The “raw” cards (new stories, bugs, ideas) are “refined” into useful outputs (estimated, prioritised stories, then technical tasks), via a series of intermediary stages and processes, with the cards taking a different form at each.

The stratified backlog

The first step we decided to take was to split out the backlog into multiple columns. The following diagram shows the columns we decided on for our first iteration of this experiment. This may seem pretty verbose, but we wanted to try be quite granular to start with and then, if necessary, merge some of these together.

Although we’re focusing on the backlog, I’ve drawn our full board for context. A couple of further points of context:

• We are currently using Zube to manage our board, which has a couple of nice features to help with this. Firstly, it has the in-built concept of a Triage column, into which new cards are created by default. This makes for a useful starting place for all cards, no matter how well defined.

• Another nice feature of Zube that helps with this system is that it allows for viewing the board in various ways. Thus when working with the backlog we can use a view that only shows the Backlog columns, and when we are doing sprint planning or day-to-day card management we can hide the backlog and show only the Sprint columns. The Release Shortlist column is left visible in both views to help bring the two halves of the process together.

• If you’re using another tool to manage your work, then labels or tags would also probably work fine for the purpose of splitting up the backlog into various levels of refinement.

Sprint meetings as “backlog refinement”

I might be overusing the metaphor a little at this stage.

The selection of these columns is not arbitrary, but to engage with the second of the two problems I highlighted earlier, a lack of focus in sprint meetings. The idea is that each movement of cards from one column to the next is associated with a sprint meeting:

Now, the focus of each meeting is very clear, almost algorithmic:

1. Take a card from one column (“input”)
2. Discuss/analyse/improve the card, then update or replace it (“refine”)
3. Put it in the next column (“output”)
4. Repeat until no input cards remain, or time runs out

And we can breakdown and define sprint meetings by their input, output, and refining process:

Buy-in from the rest of the team

The other change we’ve made is to really emphasize the importance that these backlog meetings need input from people outside of the development team. Of course product owners. But also UX/UI designers, and sometimes others. If these meetings are run efficiently their importance should be self-evident to all attendees, and the use of time is justifiable.

Being flexible

To those who worry that this is pinning things down too much, it’s worth repeating that this is just a model. In special circumstances, it is still possible to move cards wherever the team want to move them. The aim of this model is not to nail down an algorithmic process for our Kanban board, but to support the way our agile team works and to try and iron-out empirically identified problems.

Individuals and interactions over processes and tools

Alike all process changes, this is still an on-going experiment and I hope to report good things as we continue to use and adapt these ideas.

Updates

Almost immediately

The first problem identified was that our product owner immediately felt uncomfortable that it might take several meetings to get a card from the backlog straight into the release shortlist. We agreed that an approach that might work in these cases would be to have ad-hoc escalation meetings in which we essential move a card through all the columns in one go - to get an urgent hotfix or feature in the the current release.

A couple of weeks later…

After a couple of weeks with the new system, a couple of problems became apparent. It was noticed that for most stories things worked smoothly, but some more unusual cards became stuck in certain columns. I suspect these cards would have had the same problem in the old, monolithic backlog, and perhaps this new system allowed us to notice the problem better. These cards typically were hard to deal with because they had external dependencies or required a lot of analysis.