Keep your backlog brief

Your product backlog is probably too long. A quick way to tell is to look at the items at the bottom of your backlog and consider two questions: do you know their origin (who requested them and why), and assuming the team works through the backlog and eventually completes those items will they still be valuable? There’s a good chance that the answer to at least one of those questions is no, and that’s an indication that your backlog needs attention.

I often refer to Henrik Kniberg’s “Agile Product Ownership in a Nutshell” video because he covers so many key points, especially the need for the PO to say “no” so that the backlog remains relevant and realistic. The backlog should not be a place where ideas go to die! When a stakeholder says “I really need feature X” they’re probably hoping to see that feature delivered in a few weeks or maybe a couple of months – if the PO has to tell them it’s going to be 6 months or more, then why are we doing agile?

Aside from the benefit of setting realistic expectations with your stakeholders, keeping your backlog brief makes it easier to see what’s there. (This is especially useful if you use a tool like Jira which randomly adds new items to the top or bottom of the backlog!) There is also less effort invested in creating those backlog items, which means there’s probably less resistance to throwing them away when the direction changes. The same can be true for the sprint backlog. If your sprint backlog is long and unwieldy then the root cause may be that the team are breaking things down into overly detailed tasks, over committing in sprint planning, or have too much capacity (e.g. sprint is too long, or too many people in the team).

One concern I’ve heard about having a short product backlog is that it doesn’t give the team a sense of long-term stability, e.g. the team may be disbanded (or even laid off) once everything in the backlog is done. However, I think if the team are concerned about their future then there are bigger issues to address than the backlog, and artificially adding items to try to calm the team is disingenuous, contrary to the openness and honesty we promote.

The Scrum Guide describes refinement as “the act of breaking down and further defining Product Backlog items into smaller more precise items”, which is usually how product backlog items are made ready for sprint planning. I think what’s missing is the attention that a PO gives the product backlog, maybe in conjunction with the stakeholders, to prune the backlog in order to keep it focused on the upcoming needs – probably the largest part of the PO role is the communication with the stakeholders, and I think Henrik’s video gives a great overview of how much happens often without the team’s knowledge.

Coaching backlog

One challenge as a coach is deciding where to spend your time – do I help team A or team B or split my time between them? If I had the capacity to give both the attention they need then it’s not a problem but of course there’s never enough time to go round. Like so many things, it comes down to prioritisation… but what goes in the backlog? Personally, I tend to think in terms of experiments, e.g. will smaller stories improve the team’s ability to respond to changes in direction?

(I should add that when I say “team” I’m actually thinking about the people in the dev team, the other people they work with, the stakeholders, and the system which encompasses them.)

But who creates the backlog items? Obviously, there are things which come up in conversations with the team members and stakeholders, but there’s also observations and comparisons between the current system and a potential “next level”. Now, we all know there aren’t actually “levels” but there are things we tend to observe in high performing teams compared to relatively new teams. I’m not going to touch on “assessments” here – I’ll save that for a future post.

In order to share this backlog with the coaching stakeholders (which includes the team) rather than a simple backlog of Stories, something like a POPCORN board can help support the conversations around which experiments to try and what the outcomes were. POPCORN is a backronym for: Problems & observations; Options; Possible experiments; Commitments; Ongoing; Review; Next – you can watch Claudio Perrone, aka Agile Sensei, present POPCORN at Agile Testing Days 2017.