When the Scrum framework is implemented by the book (or, should I say, by the Scrum Guide), one Product Owner owns one product and works full-time in one Scrum Team.
If three decades of organizations adopting agile methodologies since they became popular in the early 2000s have shown us anything, it is that there’s the Agile Manifesto and the Scrum Guide—the theory—and then there’s the murky, complicated reality where things are not quite the same.
In your professional experience as a Product Owner, you may sooner or later find yourself in a situation where you are asked to work on two products and in two Scrum Teams simultaneously.
Should you accept?
Consider why you are being asked to become the Product Owner of a second product:
- Is this something typical for your organization, or is it a first?
- Is the ask to take over temporarily to fill a talent and accountability gap until HR hires someone else for the job, or is it permanent?
- Is the second product in the same (or in a similar) domain that reduces your learning curve, or is it in an area that’s entirely new for you?
- Is the ask in line with how you see your career evolving, and how you would like to be spending eight hours a day at work?
The answer is highly personal and highly situational, and only you can come to it. Still, feel free to use the above questions as a guide to help you make a more informed decision.
If you accept, then how do you make it work?
Make Sure the Scrum Events Don’t Overlap
Make sure that the Sprint Planning, Daily Standup, Sprint Review, and Sprint Retrospective events don’t overlap.
You don’t want to be in a position where you have to choose between attending the Scrum events of Team A or Team B, both of which you are accountable to as a Product Owner.
Whether or not the two teams’ Sprint cadences should overlap is something you need to discuss, assess, and decide with the Scrum Masters and the Developers on the two Scrum Teams.
Identify Any Dependencies Between the Teams
Are the two Scrum Teams building two different, completely separate products? Or are these two products somehow integrated or part of the same product ecosystem?
If the two products are integrated in one way or another, are there any hard dependencies between the two teams? For example, does Team A depend on Team B releasing a new version—or vice versa—to complete its work?
If the answer is “yes”, you as the Product Owner in both teams will eventually end up in a situation where Team A needs something from Team B, and you have to negotiate with yourself about changes to the latter’s Sprint Backlog.
Identifying these hard dependencies in product delivery will also prompt you—and everyone else involved—to decide whether Team A and Team B can work in parallel or whether it’s better if their Sprints overlap.
(There is no right or wrong answer, and the answer is unique to your situation; approach it accordingly.)
Gauge the Level of Commitment Required From You for Both
Does one of the Scrum Teams, its stakeholders, and/or its customers require a higher level of commitment from you than the other? What are the expectations, commitments, and hard deadlines do you need to know when working with each?
If you are concerned that you won’t have enough time to talk to the customers and write user stories for both of the products, you might want to consider onboarding a Business Analyst for one, both (one person part-time), or each of the teams (two people full-time).
Conduct an expectations and commitments audit and carefully consider if you will need help managing stakeholders (partner with the Scrum Master) or refining the backlog (partner with the BUsiness Analyst).
Consider Differences in Product and Team Maturity
Which of the two Scrum Teams is further along in the Tuckman Forming, Storming, Norming, and Performing model in terms of maturity, such that it is likely to be more independent of you as Product Owner and require less involvement?
Are there significant differences in adopting the agile mindset, Scrum framework, and approach to managing the product backlog and release cycles of the product?
As you get to the answer, it will become clearer and clearer to you which team is likely to need more of your time and decisions.
Look for Burning Fires and Mismanaged Expectations
In the short term, is one of the teams in a “the house is about to burn down” situation that requires you to put on your fire-fighting, last-minute problem-solving hat?
In the mid to long term, how are the expectations managed and the commitments made for each of the products, and how are their adoption and usage measured?
Think through your strategy as you will have to double the effectiveness—and the efficiency—of managing expectations.
For example, if the Sprint Goals of Product A are connected to Objectives & Key Results (OKRs), and its adoption and usage are measured using specified Key Performance Indicators (KPIs), there might be a case to be made for introducing a similar approach for Product B.