Product Backlog Management is challenging. Imagine you’re a Product Owner with a backlog of 300+ items. Stakeholders keep adding requests, developers feel lost in prioritization, and every refinement session is a painful, drawn-out discussion. If this sounds familiar, you’re not alone. If you have ever thought, ‘There must be a better way!’—this article is for you. Typically, many Product Owners treat the Product backlog as a single one-column list to reflect their hypotheses or perceptions about the value of each item in the backlog. While this approach has gained widespread popularity, it may not be the most effective option available. If you are:
- You are a Product Owner, frustrated with a cluttered backlog and want a structured way to manage it.
- You are a Scrum Master or Agile Coach, looking for practical ways to help your team manage their backlog beyond endless discussions.
- An Agile Leader struggling with backlog visibility across multiple teams and wants to improve Product Backlog management in multiple team setups.
If any of these sound familiar, keep reading!
In the following paragraphs, I will define the concepts of Product Backlog, Product Backlog refinement, Kanban, and Upstream Kanban. Next, I will highlight challenges arising from typical Product Backlog management. Then, we will explore a practice and concept that has proven to be highly effective in managing the Product Backlog.
Product Backlog
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. (Ken Schwaber, 2024)
Product Backlog Refinement
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work. (Ken Schwaber, 2024). Product Backlog refinement is a collaborative effort involving the Product Owner, Developers, and relevant stakeholders. It typically includes, but not limited to:
- Prioritising items based on different factors (value, urgency, business and technical dependencies, product and business strategy and many others).
- Discussing and refining details—What’s the Product Backlog Item about? What are we trying to achieve? Are there any acceptance criteria? How does it contribute to the Product Goal?
- Estimating effort – done by developers to help with planning in relation to Sprint Planning and Product Backlog Items order.
- Splitting large items—The Product Backlog is deliberately incomplete. It does not contain all the details, so when needed, the Scrum Team will divide bigger and less clear Product Backlog Items into smaller, more tangible ones.
- Removing outdated or low-value items—one of the most overlooked parts of Product Backlog refinement is keeping it relevant to the current market and up to date. As items typically maintained are the ones on top of the Product Backlog, the ones that are no longer relevant often lose focus and are forgotten to be deleted when they do not represent value from the Product Owner’s perspective.
To make it really simple, imagine that the Product Backlog is a mountain, with the top of the backlog matching the peak of the mountain. In this analogy, the Product Backlog Items at the top are typically small rocks and stones, items that should be potentially ready for development. This means that, in most cases, we should understand enough details, their size and the effort required to complete them in the upcoming Sprint. During the upcoming Sprint Planning event, the Scrum Team will define the Sprint Goal. Based on this goal, they will forecast the Product Backlog Items that are expected to be delivered in the next sprint.
Additionally, the team will outline their initial plan for turning these items into a done Increment. At a high level, this is how Product Backlog management looks. The graphic below presents the whole process.
Product backlog refinement is a continuous process. The Scrum Team should refine backlog items at different levels, ensuring well-defined items are always ready for Sprint Planning. The Scrum team should have enough Product Backlog Items at the top of the Product Backlog. The Scrum team should contribute to and manage the intensity of this activity according to current needs.
Kanban
In the Scrum team context, Kanban is a strategy for optimising the flow of value through a process that uses a visual, work-in-progress limited pull system. The flow-based perspective of Kanban can enhance and complement the Scrum framework and its implementation (Daniel Vacanti, January ). All the crucial recommendations for incorporating Kanban for the Scrum team are well defined in the Kanban Guide for Scrum Teams. This document contains some crucial and most important practices from which the Scrum team can benefit. This perception is not the only one. Kanban is also known in broader concept as a stand-alone method. A method for the definition, management and improvement of services that deliver knowledge work (Kanban University, 2024). It is still possible to enhance Scrum implementations by integrating more Kanban practices and concepts. Scrum Teams should feel free to go with it until it brings value to the Scrum team and does not violate Scrum.
Upstream Kanban
The purpose of the Upstream Kanban is to manage the stream of incoming requests before the team is able to commit to the work for execution in downstream. The upstream process is essentially a triage process: each request needs to go through several steps of selection, but not all requests need to go through the same steps, and not all of them have the same urgency (Steyaert, 2018).
Consider the scenario where your Scrum team receives feature requests from various departments: sales gather input from customers, marketing seeks to add features for an upcoming campaign, and engineering proposes performance enhancements. Without a structured approach, these requests can easily become overwhelming in a single backlog.
To improve the management of these Product Backlog Items, you decided to implement an Upstream Kanban approach. Here’s a simple breakdown of the hypothetical stages in your Upstream Kanban:
Stage 1 – Triage Stage – Start by gathering all incoming ideas and categorizing them. This initial step ensures that every suggestion is recognized and organized.
Stage 2 – Exploration Stage – Next, engage in discussions to assess each idea’s feasibility, business value, and technical constraints. This collaborative effort allows the team to evaluate each request’s potential impact.
Stage 3 – Ready Stage – The final stage might involve defining all the details required to ensure success in delivering these Product Backlog Items in the upcoming Sprint. This process helps the Scrum team to be more effective in terms of the most promising to-be-delivered Product Backlog Items.
Upstream Kanban emphasises the importance of managing options rather than simply focusing on “managing flow,” as seen in downstream Delivery Kanban systems. The goal is to ensure that there are a sufficient number of choices available at the right time while also preventing the system and the creative workers from becoming overloaded. By maintaining a balanced selection of options, we empower teams to keep the right balance between upstream and downstream and transparency in their end-to-end flow in the service or product delivery process
Product Backlog as single list – challenges
According to the Scrum Guide, the Product Backlog is “an ordered list of everything that is known to be needed in the product”. This is a great starting point for the business to list what is needed in the product.
The single-list implementation of Product Backlog has some disadvantages. Imagine that the product’s life goes from a couple of weeks to a couple of years. As time goes by, Product Backlog Items start piling up in the Product Backlog. More stuff comes in than actually comes out. Typically observed challenges when using a single-list approach are:
- Prioritisation overload – Balancing competing priorities (e.g., new features, bug fixes, tech debt, stakeholder requests) in a single list leads to constant reordering and decision fatigue.
- Lack of visibility into backlog composition – A large, undifferentiated list obscures the types of work, source of demand, and classes of service. In that case, it is hard to make a well-informed decision in terms of managing on what kind of work the effort the Scrum team is spending.
- Lack of visibility in Product Backlog refinement – When Product Backlog refinement activities are ongoing and might involve multiple team members and stakeholders, they may require multiple steps in knowledge discovery. This is becoming a complex process to manage that typically is owned by the Product Owner, who often has a busy schedule.
- Limited stakeholder insight – A single list, even when visible, may reduce stakeholder transparency. Stakeholders need transparency to trust the process and set a foundation for them to be engaged. A single list, at first glance, shares the order of a Product Backlog Item. Often, it is not enough to manage stakeholders’ expectations about the progress of Product Backlog Items that are in the circle of interest for any reason. A single column fails to show how items progress (or are actively worked on) from ideation to the moment when they are potentially ready to be pulled to the next Sprint during the Sprint Planning event. This creates ambiguity.
- Overwhelming Product Backlog size – A single list with hundreds of items becomes unwieldy, making it hard to focus on what truly matters now.
- Mixing ideas with commitments – The backlog becomes a mix of loosely defined ideas and committed work, making it difficult for Scrum team members and stakeholders to read.
As a result, the Product Owner is experiencing decision fatigue. Instead of having a well-ordered Product Backlog, the team has a wishlist of ideas, bugs, and incomplete features. This is a common issue, I have observed, with many Product Backlogs being represented as a single-list format.
Product Backlog Management and Upstream Kanban
Product Backlog refinement is the act of adding details, sizes, and orders to items in the Product Backlog. Each such activity is typically related to the process of discovering new knowledge. In such cases, we can simplify the process by treating it as one of the steps in our journey to determine what we should deliver. This concept is closely related to the idea of Upstream Kanban, where each stage in the upstream discovery or ideation process is linked to gaining new knowledge about the requirements. Additionally, this process helps us identify and potentially discard options that are less valuable.
The whole concept can be explained in simple terms. Do you remember an example where we described the Product Backlog as a mountain? On top of this mountain, typically, we have the most detailed, smallest, and potentially most wanted Product Backlog Items. In other words, the top of the Product Backlog represents the end of our process of discovering knowledge during the Product Backlog refinement. All the knowledge that ideally should be uncovered before developers decide to pull items into the Sprint Backlog is in place; any remaining knowledge gaps should be discovered during the Sprint (in reality, we sometimes need to agree to certain exceptions, especially in cases of urgent, critical, and unplanned work emerging for the Scrum Team for a very important reason).
Imagine a situation where a powerful Agile Leader approaches a Product Owner and stands in front of the backlog. With great force, the leader “kicks” the entire Product Backlog, causing it to fall, as depicted in the accompanying picture. Although this action may seem somewhat impolite, it effectively introduces the Kanban upstream process.
In this process, as more knowledge is uncovered, the Product Backlog Items become more detailed. The end goal is to have the items rise to the top of the Product Backlog, as shown in the image below. Think of your backlog like a funnel. At the top of the process, ideas flow in from various sources. As they move downward, they undergo defined steps in the process, i.e. triage, exploration, and refinement. As items progress through the process, they become clearer and more focused, increasing the certainty that the Scrum Team is willing to deliver these Product Backlog items. Only well-defined, valuable items reach the last step (representing the top of the Product Backlog), ready for development. Upstream Kanban helps manage this flow.
I hope you can imagine how, together with your team, you can map out your discovery process and reflating your ways of working. Depending on the complexity of your product, internal business and technical projects, and the preferences of your Scrum Team, you may define various steps in the process and the policies behind them.
Practice to use in Product Backlog Management
But why should the Scrum team bother about this Kanban Upstream? This is a great question! Upstream Kanban introduces valuable principles, practices and techniques that can benefit your work on the Product Backlog. In the next paragraph, we will explore some of the concepts that can be quickly adopted and benefit the Scrum Team almost immediately.
STATIK – Define Upstream Kanban to reflect your process of discovering knowledge
Each Kanban system is unique and should reflect how your team currently works. This serves as a starting point from which the team can begin to evolve and improve their Product Backlog refinement. Starting is always challenging. However, in the case of Kanban, we can use a reputable and human way to implement it; we call it STATIK (System Thinking Approach to Implement the Kanban System). In a nutshell, STATIK is an exploratory and collaborative approach that can help you get started with Kanban. It focuses on analyzing your current ways of working and based on this analysis, designs a Kanban system that is tailored to your needs. This approach is highly successful because it encourages you to consider the relationships between all the elements from a systems perspective. Don’t worry; you don’t need to be an expert in systems thinking. STATIK consists of 8 steps that a team wishing to design their system needs to replicate. These steps are presented in the picture below. More details about STATIK can be found here.
Once you design your Kanban upstream system, you will significantly increase the transparency and visibility of Product Backlog refinement and the Product Backlog itself. The Kanban system resulting from the STATIK workshop will support your Scrum team internally and externally. Internally, it will provide clarity and understanding of the current progress of Product Backlog items. These benefits will be easy to achieve in external communication with your stakeholders if you socialise your new methods of managing activities and artefacts with them.
CONWIP – a constant flow of Product Backlog Items for Sprint Planning
Kanban Upstream often implements CONWIP (CONstant Work In Process). CONWIP is a hybrid control system that supervises the process using push and pull mechanisms. This approach makes it possible to apply a pull system in industries that experience significant fluctuations in demand and product variations (Alptimur, Kafalı i Helvacioglu, 2016). CONWIP is introduced by using both the maximum and minimum number of items that need to be in each workflow stage in the Kanban System. Once the policy is implemented, we will effectively utilise a pull system, allowing us to pull work only when available capacity is in the next stage, restricted by a maximum Work In Progress (WIP) limit. While we maintain this pull approach, we will also push items to the next stage of the process to comply with established minimum WIP limits. These limits ensure that a specified minimum number of work items are always present in each process stage.
The CONWIP (Constant Work In Progress) limit provides a strategic overview, ensuring the total number of requests in progress is carefully managed. This approach optimally supports the downstream process, specifically when the Sprint Backlog is also represented as a Kanban system, enabling it to function correctly and efficiently.
Swimlane – transparency and capacity allocation for different demand
Many Kanban systems use horizontal swimlanes to enhance the visualisation of policies, types of work, classes of service, or other important attributes. Swimlanes serve as visual separations for work items in the upstream Kanban system.
They are very powerful for effectively organising your Product Backlog. Swimlanes provide boundaries to categorise your Product Backlog Items, resulting in better management of these items. Swimlanes promote collaboration by visibly indicating which tasks belong to a specific swimlane. This not only improves communication but also gives a sense of ownership and accountability.
Furthermore, setting up Work In Progress (WIP) limits or CONWIP to each of your swimlanes improves managing the team’s capacity against the demand within your Scrum during Product Backlog refinement.
Imagine that the team plans to implement swimlanes for two key categories of work: technical requirements and business requirements. By proactively managing the number of items processed at each stage of the upstream flow and within each swimlane, they can create a smooth workflow. This approach will help ensure that there is always a sufficient number of items from both categories ready to be brought into the next Sprint.
Work Item Types – a common language for understanding where your effort is spent
All elements of the Product Backlog are referred to as Product Backlog Items (PBIs). However, this does not mean that they all involve the same type of work, require similar skills for completion, provide equal value, or cater to the same group of stakeholders or customers.
In a nutshell, work items represent units of work—Product Backlog Items—that are included in your Product Backlog. Work item types are categories that group similar kinds of work items within a Product Backlog. More details on how to define both Work Item and Work Item types can be found here.
Defining the various work items and their types is essential for understanding the nature of the demand and how your efforts are allocated. These concepts help categorise your work into defined groups.
Imagine your Scrum team is engaged in developing a digital product and has taken steps to categorize different types of work items: new features, bugs, regulatory tasks, and technical debt. This thoughtful organization allows the team to gain a clearer understanding of both the demands and the efforts involved.
As they plan for the upcoming quarter’s delivery, they have reviewed the Product Backlog and identified an allocation of 20% for new features, 40% for bugs, 10% for regulatory tasks, and 30% for technical debt. By addressing this distribution, the team can consider strategies to enhance their delivery process and respond more effectively to stakeholder concerns about the pace of delivering business requirements. This proactive approach can help ensure that the team balances immediate needs with long-term product health.
Work item types can serve as a glossary that describes reality. As a result, they will help you better measure, understand, and manage the flow of work, both upstream and downstream. Benefits resulting from the proper implementation of these two concepts:
- Optimised forecasting and increased predictability of delivery of Product Backlog Items
- Improved follow-up and prioritisation for Product Backlog Item
- Efficient allocation of people and resources during Product Backlog refinement
- Enhanced customer and stakeholder satisfaction thanks to increased transparency and more predictable delivery.
Kanban Metrics – enrich your empirical process with the measures
Kanban metrics that describe your Upstream Kanban system and represent your Product Backlog refinement serve as an empirical health check for your Product Backlog refinement and Product Backlog. By tracking metrics such as:
- cycle time,
- work items aging,
- throughput,
- blockers and their source,
- discard rate,
- failure demand
You can empirically monitor the Product Backlog management process rather than rely solely on anecdotal evidence.
Consider the situation from the previous example. To enhance clarity, the team can begin by measuring the metrics associated with various work item types—such as new features, bugs, regulatory tasks, and technical debt. By adopting this approach, they will gain valuable insights into the upstream process, identify opportunities for improvement, and proactively address potential challenges that may arise downstream. This systematic evaluation can lead to more effective decision-making and contribute to the overall success of the product.
This approach will help you make more informed decisions and manage your refinement process based on solid evidence. It is recommended that you enhance the presentation of your metrics with typical Kanban charts, such as histograms, run charts, and cumulative flow diagrams.
It’s not about numbers for numbers’ sake—it’s about clarity so you can focus on what actually matters, not just what’s loudest or most obvious.
Scaling Up – The sky is the limit – manage better multi-team setup
Scaling up your delivery capabilities by increasing the number of teams involved in building your product almost often leads to increased complexity. For various valid reasons, this path may be necessary for specific products. In such cases, implementing Upstream Kanban becomes essential.
If we consider basic scaling principles—such as having one Product Owner, one Product Backlog, and one Definition of done—the most straightforward way to manage this type of environment is through Upstream Kanban. This approach supports product backlog refinement and management.
Kanban is well-known for its ability to scale to program, mega program, and enterprise levels (Meek, 2025). However, when you scale your Kanban implementation in a multi-team product delivery environment using Scrum, you may encounter multiple different Kanban systems, both upstream and downstream. This can create a unique system for information flow between various Kanban systems, helping you manage even the most complex product delivery scenarios with Scrum. It provides valuable opportunities to see the entire end-to-end value flow through the whole system, from the moment an idea is born until it reaches the user to the moment of verification of your hypotheses about the value of the Product Backlog Item.
Summary
Product Backlog management can often feel overwhelming, with hundreds of items, constant reordering, and shifting priorities. Additionally, your Product Backlog may resemble a chaotic mountain of ideas, bugs, and stakeholder demands. Many teams struggle with a single, large list that lacks organisation. Upstream Kanban could be the reset button you need.
This powerful approach helps teams refine backlog items through a structured discovery process. By visualising your Product Backlog refinement as an Upstream Kanban system, with stages tailored to your specific workflow, you can transform chaos into clarity.
Whether you’re a Product Owner overwhelmed by a long list of Product Backlog Items or an Agile Practitioner or Leader looking to help your Scrum team, implementing Upstream Kanban might be the right solution for your challenges. Are you ready to tackle the mountain of your Product Backlog and create a Product Backlog that genuinely works? Climb smarter, not harder!
If you need help with your Scrum and Kanban implementation or support in your digital, business, operation or Agile transformation, visit pawelrola.com or contact me on LinkedIn.
Let’s work together to bring the organisations of the future!
Bibliography
Ken Schwaber, J. S. (2024). Scrum guide. From scrumguides.org: https://scrumguides.org/scrum-guide.html
Daniel Vacanti, a. Y. (January , 2011). The Kanban Guide for Scrum Teams. From scrum.org: https://www.scrum.org/resources/kanban-guide-scrum-teams
Kanban University. (2024, 10 5). Kanban Glossary. From https://kanban.university/glossary/: https://kanban.university/glossary/
Steyaert, P. (2018). Essential Upstream Kanban. Blue Hole Press.
Alptimur, B., Kafalı, M., & Helvacioglu, I. (2016). CONWIP production control system application for shipbuilding process. Conference: 1st International Congress on Ship and Marine Technology. Tuzla, Istanbu.
Rola, P. (2025, 2). Work Items vs Work Item Types in Kanban: A Practical Guide. From pawelrola.com: https://pawelrola.com/work-items-vs-work-item-types-in-kanban-a-practical-guide/
Walczak, W. (2024, 01 28). Systems Thinking Approach to Introducing Kanban (STATIK). From meirik.pl: https://www.meirik.com/articles/systems-thinking-approach-to-introducing-kanban-statik
Meek, H. (2025, 1 8). Scaling A Program Using Kanban. From https://blogs.ripple-rock.com/helenmeek/: https://blogs.ripple-rock.com/helenmeek/2025/01/08/scaling-a-program-using-kanban/