Better backlogs (4) - the care and feeding of backlogs

A backlog won’t look after itself: someone has to care for it, and it has to be fed (and watered, and bathed, and clipped, and pruned…).

In a young agile project or organisation, the context for backlog items is often missing. Although an understandable reaction against big requirements (and big design) up front, preparing just enough backlog for an iteration or two doesn’t generate enough depth of shared knowledge of the team’s product. I’ve seen this particularly clearly when iterations are short: it’s hard to make sense of a growing pile of backlog items at a small level of granularity.

Backlogs are a team responsibility
Getting a backlog into a good state and keeping it there is traditionally the responsibility of the individual playing the role of customer in the team – in Scrum in particular, paying attention to the backlog is a key part of the Product Owner’s work. But this is to diminish the role of the backlog as a source of present and future conversations with and within the team about what is being built. Keeping and using a backlog well is a team responsibility. There are things that both Product Owner and team can do to keep the backlog in good shape, and things that can kill it. Think of it like a houseplant – it will start small and grow, but it needs water and feeding. No water, or too much water, no light, the wrong temperature, all these will turn your plant into a dry and brittle twig.

If a Product Owner cares about his requirements but regards the backlog as a mere side effect of requirements management then it’s unlikely to be useful. It can rapidly turn into a dead-letter box for the team’s work – and worse, if there’s no conversation around the backlog and it’s seen simply as an ever-growing list of stuff for the team to do, it can be positively de-motivating. This happens particularly easily if the Product Owner has come from a traditional product management background – requirements documents are much more comfortable as an artefact.

To sustain meaningful conversations around the product, the backlog must reflect current knowledge. To be available for those conversations, it must be easily accessible and visible to all the team. And to ensure that those conversations happen, you need to embed the backlog into the Product Owner and team practices.

Team practices for better backlogs
In Scrum the standard points of contact of team and Product Owner with the backlog are release planning and iteration planning. There’s no shortage of writing on agile planning covering both of these, but it’s not uncommon for people to miss the important side-effects of preparing and running these sessions by concentrating on the ostensible goal of producing a release plan or an iteration commitment. As before, I’ll use the Scrum terminology in the outline below: change the terms to suit your agile methodology of choice.

As Product Owner, you need to understand the structures of your product’s requirements. For all but the simplest products, there are going to be distinct user roles, activities, time-dependent patterns of use, operations on different parts of your product’s domain model – these add up to multiple ways of organising requirements, but key to producing effective items of value is understanding user roles and interactions. Use these to define high-level feature groups (call them Epics or Themes if you wish), and drive down into the key user interactions that define the key value of your product. Capture these how you like – as user stories, in storyboards, prototypes or mock-ups, but please capture them in a distinctive form – one that doesn’t require you, the team or anyone else to wade through pages of requirements documentation. And make sure that they are consistent and comprehensible – read the post on Backlog Smells to understand what to avoid, and how to deliver useful backlog items.

Effective release planning
Having understood your product to this level of detail earns you the ability to perform release planning effectively. Release planning is the team practice that keys the backlog as a whole into the team’s consciousness: you’ll get a lot more out of the process if it is adequately prepared. If you’ve understood the structure of your product requirement, you’ll have items ready for the backlog defined at a level above that of an iteration item (you need these particularly if your iterations are short and releases are long). You’ll have a way of organising that backlog so that relationships amongst items are clear, grouping them by one of the structures you’ve already identified – user role is common, but it could be around feature groups or any other structure in the requirements. The organisation becomes even clearer when cards are used for the items being estimated – arrange them in groups at the start of the release planning meeting to make the structure clear, then use whatever methodology you’ve settled on (planning poker, categorisation into “buckets” of relative sizes, there are several such techniques) to make your high-level estimates to allow you to scope the release.

To emphasise – the primary goal of release planning is to estimate and prioritise items at a high level for a release, but the side-effect is a shared and common understanding of the structure of the product’s requirements. The whole team has seen and worked with the structure of the backlog. Getting to a plan without generating the understanding simply misses the point.

Iteration planning, review
Preparation for iteration planning involves a conversation about the next most valuable items to deliver. These may already be at the level of backlog item, but more often than not the Product Owner will want to start work on a higher-level item. This fine-grained preparation of the backlog can be done a few days in advance of the iteration planning meeting, and should involve two or three team members as well as the Product Owner: this is a great opportunity for the Product Owner to continue to educate the team on the project’s business priorities, and for the team to educate the Product Owner on technical factors which may change scheduling priorities (arising from internal or external dependencies, for example).

Iteration planning deepens a team’s knowledge of the backlog to the point at which the work to deliver the next iteration’s items is understood collectively. The activity of driving down items into iteration-sized chunks and then into engineering tasks enriches the awareness of the product, but it can only do this if the context is understood. Just as release planning builds common understanding of the structure of the requirements, iteration planning deepens that understanding and shares the detailed knowledge of the work that’s needed to deliver the value of the committed items.

Finally, iteration review provides an opportunity to revisit the backlog in the light of what’s been learned during the iteration. Re-estimation is almost always a bad idea, but re-prioritisation on the basis of new knowledge or experience should be expected and welcomed. The new knowledge will influence the way subsequent backlog items are reviewed and prepared for iteration planning.

Evocative documents
Amr Elssamadisy identifies Evocative Documents as an important pattern of agile adoption – a document which on the one hand is a promise of a conversation (Ron Jeffries’ notion for story cards), on the other hand something which recalls a memory or a context of a conversation. Evocative Documents are distinguished from Representative Documents, which aim to be definitive. The XP Story Card is the quintessential Evocative Document – it may have no more than a sentence or two describing a user story, but serves as both a focus for planning and implementation, and as a social object around which those activities occur. If a backlog, and the items on it, is to be more than just a to-do list for the team, everyone involved in backlog work needs to take care that it starts and remains evocative. The backlog has to be available (it seems bizarre to me that some agile support tools don’t let a project team review and enhance backlog items) and current (so the Product Owner and the team need to pay enough attention to the backlog to keep it so). The more a backlog is regarded as a peripheral artefact, the less useful it is.

No Comments

Add your own comment...