One overloaded Product Owner, two teams, and a Slack back channel
At an online retailer, one Product Owner serves two Scrum Teams of seven and eight people. She is also Head of Product and the line manager for four team members. Production incidents consume roughly 60% of her week; she approves release hotfixes and answers escalations from the operations director. Because she has little time for refinement, a senior architect writes the user stories and assigns estimates, and the teams treat his estimates as commitments. Marketing, legal, and operations routinely message developers directly in Slack with 'small' requests, and several have landed in sprints without the PO seeing them. Sprint reviews are 45-minute demos to twelve executives, with no discussion of what to do next. About 40% of each sprint's committed scope changes mid-sprint, usually approved verbally by the PO to keep stakeholders happy. Velocity is erratic, and two developers say they no longer know what 'done' means for the product.
1. Is this Product Owner arrangement viable? Analyse the decision rights involved and identify what can be delegated and what must change.
Read the worked answer
The arrangement is not viable as it stands, for reasons that are structural rather than personal.
Accountability. Scrum assigns one Product Owner per product, accountable for maximising value. That accountability cannot be shared or delegated away. It is fine for one PO to serve two teams if the PO has the capacity; here the PO is effectively an operations manager who also orders a backlog in her remaining time.
Availability. With 60% of the week on incidents, refinement, stakeholder work, and review preparation get the leftover hours. That is why the architect is writing stories and why mid-sprint changes go unnoticed. Either the operational load moves to an operations function with a defined escalation threshold, or the product is split with a second genuinely empowered PO.
Line management. Being the line manager of four team members conflicts with self-management: the person who orders the work also writes their performance reviews, which suppresses candour and pushes the team toward pleasing the PO rather than solving the problem. Move line management elsewhere.
Delegation. The PO can delegate refinement facilitation, story drafting, stakeholder liaison for a bounded domain, and acceptance-test coordination. The PO cannot delegate ordering, the value judgement, or the final call on scope. A proxy is acceptable only with real decision rights; otherwise it is just a bottleneck with extra steps.
2. Marketing, legal, and operations are bypassing the PO and putting requests straight to developers. How should the PO respond?
Read the worked answer
The bypass exists for two reasons: there is no other route that feels responsive, and the PO has taught stakeholders that bypassing works by approving requests verbally mid-sprint. A ban without a route will fail.
Give them a single, visible intake. All requests go into the backlog with a published service level: acknowledged within two working days, decision at the next refinement, with a stated reason if declined. Publish the order and the criteria so stakeholders can see where their item sits and why.
Make the cost of unplanned work visible. Show the sprint goal, the items displaced, and what slipped. Stakeholders rarely see that a 'small' request costs a completed feature.
Protect the sprint goal with a rule. Mid-sprint, the choice is a swap (an equal-sized item leaves) decided explicitly by the PO, not an addition. Genuine incidents go through a separate expedite lane with a cap.
Work the relationship. Meet the three stakeholders individually to understand what they are really trying to achieve, and agree which of their needs are routine and which are urgent. Developers should redirect requests politely, and the Scrum Master should reinforce the process. If the PO keeps verbally approving, nothing will change - the PO is the root cause as well as the fix.
3. The architect writes the user stories and estimates, and 40% of sprint scope changes mid-sprint. What is wrong and what would you do?
Read the worked answer
An architect contributing technical constraints and enablers is healthy. An architect owning story content and estimates, with the team treating those estimates as commitments, is not: the team loses ownership of the 'how', the PO ends up ordering someone else's backlog, and estimation becomes a promise rather than a forecast. Move estimation to the team using relative sizing, and reframe the architect's input as constraints, options, and risks. If the architect is effectively acting as a proxy PO, make that explicit with decision rights, or stop it.
The 40% churn is the bigger problem. It means the sprint goal is fiction, velocity measures noise rather than capacity, and the team cannot finish anything cleanly. Three changes:
- Write a sprint goal that expresses a user or business outcome, not a list of tickets.
- Adopt a scope-change rule: swap, do not add; the PO records the decision and the trade-off.
- Instrument the churn. Which stakeholders, what kind of request, what was the cost of delay?
That data usually shows whether the ordering model is wrong (the PO is not seeing demand early enough) or the stakeholder process is wrong (no agreed cadence). Fix the cause, not the symptom.