The nine zones of my product backlog
I am the product owner and business analyst of my organisation’s new data platform that has an architecture with three layers: Raw, enriched and curated. Also known as bronze, silver and gold. I like to think of my backlog going through the same stages as it matures and develops. Everything that is simply added to the backlog as a wish, is in the raw layer. When scope is being refined it is in the enriched layer. And when scope is ready to be communicated to stakeholders, it is in the curated layer. My backlog is structured in a hierarchy of requirements that in the product backlog management tool Microsoft Azure DevOps consists of epics, features and user stories.
When combining the hierarchy with the layers, then my backlog can be illustrated as below:
Ideally, I have some work placed in all nine zones. This indicates that product development is progressing, while still being able to develop the product strategy and make it operational.
Epics
The scope of the product can be defined by a business model canvas, project charter or similar. As an example, I have an epic on my data platform product backlog with the objective of making easily available consolidated insights about who our members are (as an association we have members, not customers). This provides guidelines about what to prioritise, but it also helps me to exclude scope from prioritisation. For example, insights needed to optimise internal processes — even if data is available from the source system — is out of scope until we have decided to start working on an epic that addresses internal process optimisation.
Raw
An epic is a larger, logical part of a product. For example, a business capability (enterprise architecture) or a domain (Domain Driven Design).
Enriched
The scope of the epic can be described using OKRs or another format for describing high level business objectives. A conceptual diagram is also useful or a story board. If the epic is an AI model, the AI canvas is a well-suited format.
Curated
It is quite simple to set up a dashboard in Azure DevOps that lists the epics on the product backlog with a link to a description or presentation of the product vision. This is relevant information for product management.
Feature
Epics are broken down in features. As a consequence, the scope of the feature must be within scope of the epic. It is important to note, that not all features in an epic need to be in the same zone. If an epic has five features, then one can be in the curated zone, one in the enriched zone and the rest in the raw zone. This is — among other things — what it means to be agile. Status can be used to communicate which zone the feature is in, just like the user stories.
For me, the features are the key to a healthy backlog. The effort put in maturing features and aligning their scope with stakeholders is well spent, because it ensures higher quality in the user stories and less rework.
Raw
A suitable level of granularity is for example a business process or use case complete with alternative flows, business rules and non-functional requirements.
Enriched
All the good, old diagram techniques are suitable for describing features. Such as process flows, use cases and information models. Just remember, that an information model can not stand alone. It needs to be complemented by something that describes the context the data will be used in, including who the users are. When working with data for analytics, a description of the decisions that users need to be able to make with the data is well suited.
Curated
Features in an epic can for example be presented on an Azure DevOps dashboard with the description included so you have a coherent view of the scope of the complete epic. It can also be described in a Visio-file (or similar format) or on a wiki-page. Often different epics have different stakeholders. By setting up separate dashboards with the scope of features within an epic, information to stakeholders because targeted to their specific need.
Product backlog items
Features are broken down into user stories. As a consequence, the scope of the user story must be within scope of the feature. The feature provides the team with the required context to create a future proof design and to make sure that necessary work related to architecture and security is also included on the backlog.
Raw
User stories are identified and can be refined.
Enriched
The user story is complete with description and acceptance criteria. Test cases can be used as an alternative to acceptance criteria.
Curated
The Azure DevOps dashboard with the scope of the features can be expanded to also include the scope of the user stories. Remember, that description and acceptance criteria can also be included in a query displayed on a dashboard. It is easier for stakeholders to follow progress of product development if they can follow progress related to a feature, rather than from a sprint backlog.
Forget about defects (or bugs)
Bug is a standard work item type in Azure DevOps and back when I started working with software development 15 years ago, they were important for quality assurance. But this was back when test management was done in a stand-alone tool. Now that I manage requirements and testing in the same tool, I don’t need them. I just need the test case linked to the user story. Any bugs found in the test can be added to the discussion field of the user story, making it simpler to trace back what happened and limiting the number of work items to manage. As for bugs found in production, it adds no value to register them as bugs (as opposed to changes). When in production, the discussion of what is a bug and what is a change is just fruitless.
Why not just use User Story Mapping?
In my opinion, user story mapping is not an appropriate technique for user stories related to larger innovation initiatives. When instead breaking down work hierarchically, all work can be traced back to the strategy and thus easier to prevent scope creep. Prioritisation is easier, because it is only needed to prioritise between features within a prioritised epic, and only needed to prioritise user stories within prioritised features. Also, work items are to a higher degree created just in time. This means that you have fewer user stories to manage on the backlog.
It is however appropriate to perform user story mapping, when it is needed to organise and prioritise a number of change requests that come in on a continuous basis.
Implementing a hiearchy in Microsoft Azure DevOps
The hierarchy of requirements is standard in Azure DevOps and looks like this:
When using the requirements hierarchy, it becomes trickier to read the product backlog. The backlog can be viewed on all three levels and it is important to be aware of which level is being viewed:
Underlying methodology
The philosophy behind a hierarchy of requirements is explained in the Business Analysis Body of Knowledge (BABOK), which is developed by International Institute of Business Analysis. In this standard the hierarchy consists of business requirements, stakeholder requirements and solution requirements. The standard primarily consists of a number of knowledge domains that provide a framework for refining requirements and collaborating with stakeholders. It only includes descriptions of many modelling techniques.
