There’s a aspect to owning a product backlog that a lot of Product Owners struggle with; how do they handle all the little requests? All the relatively tiny, inconsequential backlog items, customer requests and minor improvements that in and of themselves have very little value, but combined have a lot of value in that they help improve the overall quality and polish of an application. These are the “white noise” items, the constant background hum of a Product Owner’s life and can be the main thing that Product Owners have to do that feels like administrivia and can in turn make them want to stop managing a backlog at all.

For most Product Owners setting the delivery order of items with obvious business value and significance such as key initiatives or small but critical fixes and improvements is fine. It’s something that they want to do, that they can grasp and put their heads around, something that makes sense to them, but when that same Product Owner is faced with a bucket load of tiny requests each with small individual business value, then it’s not uncommon for Product Owners to simply throw their hands in the air, and out them at the bottom of the backlog effectively ignoring these items because ordering them is simply too difficult. “I’m meant to order my backlog by value and return on investment, right?”, say the Product Owner, “but these tiny items feel more like shuffling confetti by size and weight and none of them are more important than all these other larger, more obvious items I have”. What they’re forgetting is that the confetti sized items have potentially massive value when looked at as a whole. They’re the paper cuts that people feel with a product, the little niggling things that combine to give a product an overall sense of incompleteness, and ‘not quite what I expected’ quality.

So let’s get pragmatic about backlog ordering then, shall we?

In Scrum, a Product Owner is tasked with optimising the value of a product and of working with the development team to ensure maximum Return On Investment and a low Total Cost of Ownership. At the same time, an agile team should be learning constantly and aiming to be as productive and as efficient as they can be and spending a lot of time ordering these tiny backlog items is hardly efficient.  How can we achieve both goals, and maximise value whilst staying efficient?

What I’ve done with a number of Product Owners now is to ensure that the PO is ordering all the non-trivial Product Backlog Items in the backlog as per usual, and then developing a working agreement/convention with the development team for dealing with the tiny items. During sprint planning the development team uses about 80-90% of their forecast for the planned, deliberately ordered Product Backlog Items, and then grab tiny items from the backlog until they think they’re good to go.

imageIn terms of managing this via the backlog, we still keep a single backlog (duh!), but organise it into sections. The top section are the loosely planned product releases, with items specifically ordered in the releases. Obviously, if the product doesn’t have releases and is deployed continuously or very regularly then the top section is simply the collection of product backlog items that are explicitly planned. This section is then followed by the “tiny items”. These items are also ordered, though ordering is done via conventions or rules* so that no manual ordering is required. Finally, we ensure that the development team and Product Owner are clear that items from the release section of the backlog are the more important. Should something happen during the sprint that requires scope to be removed from the sprint, then it will be the tiny items that are taken out first as they are lower in value than the planned items.

Of course, if the Product Owner specifically wants a tiny item worked on, they simply move it into the planned and ordered Release backlog section, just like every other item that they have placed there.

At the end of the day this doesn’t remove the responsibility from the PO to order the items or to focus on optimising value, but it does mean they don’t have to worry about ordering the metaphorical grains of sand in the jar, just the bigger rocks.

*P.S. For an ordering convention, I usually suggest alternating a small bug fix with a small improvement, then order by a value grouping such as Small, Very Small, Teensy, and then by date created, in descending order. As stated above, if the Product Owner wants a tiny item delivered in specific order, they just pull it up into the main explicitly ordered section.