The product backlog is the most important artifact in any product development company. How should we structure this critical artifact? Let’s look at six product backlog examples, while asking, “How can the product backlog help us drive development forward in the right direction?”
[toc]
➡️ Effectively Manage Backlog with Helix plan
Before You Get Started on Your Backlog
To know whether the backlog will drive development in the right direction, you need to know who wants what from it.
- As a team member, I want to know what user stories to work on next with an understanding of how my work fits into the overall matrix.
- As a product owner, I want to see how features are progressing so I can adjust and refine priorities with the team.
- As a project manager, I want to see how the product develops and how overall progress is going.
- As a stakeholder, I want to know when my thing is ready.
Product Backlog Example 1: Team Organization
A backlog structured around team organization does just that: Its hierarchy is shaped by the shape of the organization — by the different teams working on the product. For example, Team A, Team B, Team C. Or Team Yellow and Team Blue, as above.
A few things happen when we structure this way:
Teams Can Resolve Dependencies
When they can see their backlogs side by side, teams with strong dependencies among each other suddenly have some visibility they didn’t have before. Such an arrangement makes it much easier to communicate and resolve dependencies.
User Stories Can Lose the Context
What happens when we organize by team is that user stories become orphaned from big picture goals or strategy. One workaround is to complement this method with heavy use of release tagging for goal setting.
Products can Take New Shapes
It’s been studied and proven. For better or worse, products themselves tend to take on the characteristics of the organizational structures that create them. See Conway’s Law and its many corollaries.
Product Backlog Example 2: Process
A second way to structure a backlog, common in more lean-oriented organizations, is around the workflows and processes required to pull an idea through the pipeline to release. Simply, you may have certain processes for managing your product lifecycle that you want to see reflected in your product backlog.
A few things can happen when we structure this way:
Workflow Can be Optimized
When we structure the backlog by high-level process steps, we can keep close eye on the flow between and among each step, and find ways to optimize it.
Backlog Size Can be Limited
A process-oriented backlog is especially useful in situations when the product owner is good at saying no, and they want to keep as few items as possible in their backlog.
Stakeholders Can Participate
With this setup, stakeholders can contribute easily by having their own special spot in the backlog, sometimes called a “wish list.” If accepted, their ideas move into the product backlog and begin flowing down the pipeline.
User Stories Can Lose Context
Like example one, user stories in a process-oriented backlog can lose critical context regarding where they fit into the over-arching picture.
Product Backlog Example 3: Components
Rather than by organization or process, you may want to organize the backlog around the product and create a work breakdown structure of product components, or deliverables, being developed.
A few things can happen when we structure this way:
Product Modularity Can be Supported
If you’re organization sells many parts or components of a product (rather than the entire product) to third-party vendors, organizing by component can help understand progress per order or vendor.
Traditional Planning Methods Can Excel
If you use traditional planning methods, this structure makes it easy for planning and committing over to a Gantt schedule, which in turn can help understand what leads up to an entire component being ready for production.
Overhead Can be High
This structure requires a lot of detailed thought and planning up front — before anything is built. Depending on what you are developing, you may be creating a lot of overhead, especially if you’re building a backlog for a product without precedent.
Managing Dependencies Can be Difficult
When change happens (which it often does these days) resolving resulting dependencies make it difficult to deliver a useful feature without a lot of legwork and hassle.
📘 Related Resource: How to right-size your backlog
Product Backlog Example 4: Planning Horizon
A fourth way to structure the backlog is to use the planning horizon. The planning horizon, a five-stage concept common to many product development organizations, starts high at vision and works down many layers to daily commitment.
- Product Vision
- Product Roadmap
- Release Plan
- Iteration Plan
- Daily Commitment
Organization by planning horizon can do the following:
Stakeholders Can Easily Understand It
Remember, as we mentioned in the beginning, many stakeholders just want to know “when their thing is done.” Structuring by planning horizon helps the stakeholder understand exactly when they can expect what.
Team Commitments can be Hard to Delineate
An obvious challenge with this structure is finding a useful, valuable way to separate this plan from a commitment from the team, in a sprint for example.
Product Backlog Example 5: Type of Work
So much more work goes into a product than the features it provides — bugs fixes, refactoring, process improvements. A product backlog organized around these different types of work can ensure we lift our focus off the shiny feature and place it on other types of work necessary to deliver value to our customers.
Here’s what can happen when we structure around type of work:
Teams Can Evenly Distribute their Attention
With this structure, it is easier to tell teams to pick at least one thing from each bucket of different work items. It’s also easier to understand work distribution among different types.
Classes of Services Can be Simplified
This approach is also useful when using different Classes of Services (and a column attribute is not enough).
Value Can Become Invisible
Organizing by type of work can be problematic when it means we forget about value, which should always be top of mind. For that reason, we recommend including type of work as a single column rather than letting it dominate backlog structure.
Product Backlog Example 6: Goals
With the caveat that there are many ways to structure a backlog, we will now cover the structure I recommend the most: a goal-driven backlog. In which, we aim to capture the goals and vision of the product broken down to sub-features.
Here’s what can happen when we structure around goals:
Teams Can Stay Focused on Business Value
The benefit with this structure is that it all but guarantees that teams are:
- Focusing on items with high business value.
- Improving the right things in the product.
Work Can be More Measurable and Accountable
By defining these high-level goals (also called “business epics"), we can create quick, measurable feedback loops to understand whether we are working on the right thing or not. Also, we become held accountable for meeting our goals, which we see every day in the backlog.
Build Your Backlog Now
That’s it! Six product backlog examples to structure an Agile backlog. As I mentioned earlier, it is often a combination of these approaches, not just one, that is used for best results. The key is to have a systematic approach to how you build and structure your backlog — especially in large-scale contexts — and improve from there. Results will follow.
Learn more about Helix Plan (formerly Hansoft), the better backlog management tool.