Dual-track Product Backlog Management
Balancing major product roadmap features with ad-hoc requests
In most successful product development organisations, no matter the size of the team, product managers need to manage priorities between product roadmap features, and a variety of internal requests which may range from marketing/sales, business intelligence and operations. Some of the most commonly asked questions when talking to other product managers are:
- How to identify prioritised features to design and develop, and get stakeholders’ buy-in?
- How to balance new feature development with quality improvements of the current features?
- How to maintain or improve the velocity of innovation without compromising on user experience and product quality?
- How to balance the needs of internal departments and operations while staying focused on delivering value for customers?
In this post, I propose a dual-track method for product backlog management process, which aims to address challenges in resource-constraint product teams to balance innovation needs, quality standard and operational efficiency.
What is “dual-track product backlog management”?
In summary, the dual-track product backlog management approach separates major roadmap releases with ad-hoc issues and requests. As I will explain below, this approach of product backlog management has the benefit of making it possible to commit to a fixed roadmap release schedule, which are important milestones for achieving company performance goals, and smaller non-roadmap product requests and issues. Without the ad-hoc track, product teams may run into situations where non-roadmap issues such as UI consistency, operational efficiency improvements are being postponed indefinitely, resulting in legacy issues which may be harder to resolve later.
The roadmap track
The roadmap track consists of major product releases and milestones. In addition, the release schedules for certain projects are sometimes fixed by external contracts and are therefore required to be followed and executed exactly.
Usually, roadmap track items should take up the majority of time commitment and development resources within a sprint, to allow focused uninterrupted time allocated to roadmap features which are aimed at bringing major performance improvements. Based on my experience, around 80% of the time should be reserved for roadmap items for each sprint for better feature development velocity.
In terms of priority, the roadmap track items, in general, have a higher priority than ad-hoc track tasks, with the exception of urgent issues or fixes that requires immediate attention.
The ad-hoc track
The ad-hoc track has two types of tasks: urgent issues and planned ad-hoc tasks. Urgent issues are usually incidents or escalations from support teams. Issues in this category require most immediate attention to avoid further escalations of the severity and impact of the raised issues. Due to the disruptive nature of such tasks to overall dev productivity, it is recommended to keep urgent issue to a minimum and have a set of strict criteria to determine whether an issue is actually urgent.
On the other hand, planned ad-hoc tasks may contain a variety of internal product development ideas within the team or from other departments, and is usually not time-sensitive. Compared to roadmap items, planned ad-hoc tasks are usually smaller in implementation effort and impact. Without the dual-track product backlog management approach, these tasks are not very likely to be prioritised for development when the product manager is using a single track roadmap priority list.
Implications for development sprints
As mentioned, the benefit of the dual-track backlog management approach is its flexibility in balancing major roadmap items and smaller ad-hoc tasks. However, a dual-track backlog may be challenging when it comes to sprint planning and estimations. Therefore, the dual-track backlog management approach is useful for the product manager to prioritise and select items for the upcoming sprints and move or translate these product development tasks into a single development sprint backlog ready for implementation. This extra step will reduce confusion within the development team and ensure efficient sprint planning discussion meetings.
We are constantly on the lookout for great talents to join our team. Visit our careers page to learn more and feel free to reach out to us!
