Who is responsible for the product backlog? For many Agilists, there is only one answer - the Product Owner (PO), and by definition, that's correct!

The PO is in fact the only one accountable for the product backlog, and they are the person in charge of keeping it organized and prioritized. As a business representative, it's up to them to work hard so that the backlog reflects the product vision, leveraging high priority features, release dates, defects, and even tech debts.

However, the PO naturally has a myopic vision of the technical challenges due to his or her business mindset. There are scenarios where a PO often ends up deprioritizing technical activities due to "business urgencies”. This scenario is aggravated in large corporations that usually apply Scrum of Scrums (SoS) with common goals and deadlines across components for the same product. Among the possible solutions that can help mitigate this problem, one that seems to be widely applied by companies is the sharing of backlog maintenance with a technically skilled professional.

The Scrum Guide defines the PO role as “responsible for maximizing the value of the product resulting from work of the Development Team”, which means acting on different areas and activities such as: prioritizing user stories based on business value, effort, and urgency - as well as groom user stories in order to ensure that all scenarios and details are sufficient enough for sizing and implementation. Along with operational activities, there’s a constant challenge to manage the tension between the business' desire for new features to help enhance the user’s process, and product foundational upgrades along with the need for technical debt reduction.

So, how would the mechanics of shared responsibility work? Check out these scenarios below:

Choosing a Development Team Member to Help and Facilitate Technical Understanding

This is usually the first option when applying shared responsibilities. It shouldn't be difficult to identify a team member that stands out due to their technical background and communication skills - this person will most likely be the go-to person for the PO when they need clarification around a technical subject. In this case, the PO will partner on demand with this member, inviting them to prioritization sessions to give more visibility to the technical aspects of the product. This strategy is frequently utilized as a dry-run to learn more about shared responsibility, and can be adjusted as needed.

Creating a Product Owner Team (POT)

This next option is slightly more structured. In this scenario, a team is created consisting of professionals with diverse and complementary skills (usually a PO, Tech Lead, Business Analyst, and QA Lead) who are all responsible for ensuring that the backlog reflects both business and technical needs. This team will basically be composed of key members who will collectively be accountable for the backlog prioritization - which could be considered a better, holistic approach. However, this approach goes against an explicit definition in Scrum Guide that states that the PO role must never be a committee. That's because a committee brings complexity to the decision-making process, making it bureaucratic and necessitating that everyone's ideas are considered. 

Creating a Technical Product Owner (TPO) Role

Often mistaken with the POT, this role does not involve a committee or group, rather a single professional with technical skills, such as an Architect or Tech Lead with the goal of advising and assisting the PO in technical matters only. The TPO works closely with the PO assisting the general prioritization process by providing technical inputs considering architectural dependencies, impacts, and blockers. The PO may even delegate the technical part of the backlog to the TPO, but it’s important that they do work together to ensure that both sides are familiar with the "other side” and are running towards a unique and common goal. Together they have a better and balanced backlog due to a more realistic and sustainable prioritization. On a daily basis, the TPO would be responsible for presenting any technical content to the team, signing off on technical cards, and being the overall technical reference throughout sprint planning.

In Conclusion

Each case has its own nuances, and each company and project may have a different fit or work better under different circumstances. I’ve witnessed startups with high performance projects achieve amazing delivery rates where a single and different developer would partner with a PO on each rotating sprint. Same concept, different flavor.

I've also worked on many large-scale projects with different formats, and the most effective model applied was utilizing the TPO role. Having a TPO role drastically improves the planning phase as well as the product itself. In a few companies with these projects that I've worked on in the past, there wasn't an acronym/title for the role, but the role formed naturally after the PO partnered with the Architect. Even when PO has a technical background, I believe that delegating the technical aspect is the best way to go because it will allow the PO to focus on business like activities. 

A good rule of thumb is to consider your project and team structure. Talk to everyone to get their agreement and commitment. You can always improve this process over time - after all, it's Agile!