Keeping the backlog structured, visible and relevant (for stakeholders)
I have worked in numerous setting in which an entire team had to develop more than one product, or a rather big product (or product line due to proper domain scoping).
There were questions as to the scope of one particular backlog: Should it span just one "tiny" product (like a microservice for "Orders"), or a user-centric product (like a webshop) which internally has requires orchestration of sub-products (and/or sub-teams), or should we model the backlog around an entire team (which was usually the way it went)?
In either case, one phenomena started to appear: The backlog grew and grew, and even with proper attendance and cleanup, it started to become messy. Not due to bad naming or scopes, not even due to a lack of priorities. Simply because it's a lot.
And, moreover and most importantly, it became almost impossible to "read" the context of these simply listed items. Because it's just a list, there is this cognitive overload for mentally associating them to their proper place.
In all these years of experimentation as a Scrum master (and sometimes Product Owner), I came up with different solutions, which all came with upsides and downsides. Examples include:
- Using containers like Epics, Features, etc. as long-standing product areas
- Horrible idea in retrospect, because they are supposed to be true projects with fixed scope and timeframe
- Using containers like Epics, Features, etc. as scope-driven delivery packages (e.g. for releases with version X)
- It worked well to some extent because it gave each backlog item a background story and some context
- Drawback: Relapse into old fashioned project thinking.
- Using "area path" dimensions (Azure DevOps) for product aspect
- Using tags
- Using various dashboards for filtering backlog items based on various perspectives in order to help understanding the backlog
But in the end, for the Sprint planning, I must use the one backlog list with a fixed priority, which is of course a good thing because it enforces the priority.
But nonetheless, many stakeholders are left stranded when you're handing them a link to the backlog itself or even just a list. It's just missing context.
So, after a long introduction, my question:
- What means to you use to improve the readability and relevance of the backlog?
But nonetheless, many stakeholders are left stranded when you're handing them a link to the backlog itself or even just a list. It's just missing context.
That's the problem, and you won't get that context just by improving the readability and relevance of a backlog. The context is empirical feedback from a Done increment at least once each and every Sprint.
This is the context which ought to be immediately present in stakeholders' minds, even to the point that a Product Owner ought to be ready and willing, at all times, to kill their darlings by revising a Product Backlog completely.
Maintaining the backlog is the accountability of the Product owner(who will work with the stakeholders of course) and I agree with Ian the key word is indeed FEEDBACK which will help the team to hear it from the stakeholders about how relevant is the product/software being built. I normally prefer to take 2 feedbacks during the sprint review one for the work done and one on the road ahead (basically the next set of items in the backlog which is planned for upcoming sprint...arrive at this through backlog refinements).
Also the team needs to spend sometime in doing a backlog refinement to ensure that the backlog items are clearly understood and prioritized (target to have work for the next 2-3 sprints ready).
One of the premises of the agile software delivery movement was to have the ability to react to change. One of those changes is that over time, things that have been asked for in a product are no longer relevant. Backlog management should include the act of removing items from the backlog if they are no longer needed. Remember that the Scrum Guide states:
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team
If there are items in the Product Backlog that are no longer "needed to improve the product" then why keep them there? Would you keep a task on your gardening list to fertilize the plant by the front door if that plant died? The Product Backlog is not a dumping ground for ideas. It is a list of activities that make the product better for the stakeholders.
One exercise I suggest to all any team in which I have an encounter is that they all commit to spend an hour a week looking at the items at the bottom of the Product Backlog. This gives them all an opportunity to suggest items that may no longer be relevant. The Product Owner can then reach out to stakeholders to determine interest and make a decision on whether it is still viable. This exercise has lead to a large number of items being removed from Product Backlogs and helping those backlogs become less daunting.