The PM Who Rewrites Your Stories

The split is by backlog, not by seniority. The Product Manager is the content authority for the program backlog: the features, their benefit hypotheses, and the economic prioritization across teams. You, as PO, are the content authority for Team Atlas's team backlog: the stories, their acceptance criteria, and the order in which the team works inside the iteration and PI.

The PM editing acceptance criteria is not automatically wrong in substance - feature-level acceptance criteria are hers. But editing story-level criteria directly in your tool bypasses the single owner the team looks to, which is exactly the confusion the Scrum Master is reporting.

Apply it concretely: ask her to state the feature-level outcome and constraints, and you translate them into story-level criteria with the team. If she wants a criterion changed, it comes to you as a request with a reason, and you decide how the team backlog reflects it. Where her edit is a genuine correction - a regulatory detail, say - take it, credit it, and fold it in yourself so the team still hears one voice.

The trap is treating this as a hierarchy question. It is a decision-rights question: you are not her subordinate on team backlog content, and she is not yours on which features exist and why.

Do not answer with a policy quote. Answer with data and options.

1. Get the facts first: which feature, why now, what the demo must actually show, and what 'done enough to demo' means. A demo often needs 30% of a feature, not 100%.
2. Put the constraint on the table: Atlas is at ~95% of iteration capacity with two features in flight. Adding work means something comes out.
3. Offer two or three concrete trades:
   • Swap: identify the lowest-value committed story of comparable size and defer it to the next iteration - you propose, she agrees.
   • Slice: a thin, demo-able increment, if it can be built without destabilizing the two features in flight.
   • Stage: demo via a scripted walkthrough now, full build in the next System Demo, protecting the committed PI objective.
4. Close in writing with the decision and the trade recorded.

What you do not concede: a unilateral insertion, a vague 'we will find the capacity', or a commitment made on the team's behalf without asking them. Bring the real cost back from standup before you commit to anything.

The trap is a flat no. The demo is a legitimate business need; your job is to make the cost and the alternatives visible so the PM chooses, rather than to defend the plan as if it were a contract.

Escalate on process, not personality, and only after you have specifics recorded: dates, stories, what changed, and the effect on the team.

Sequence:

1. RTE / PO sync first. This is a cross-team backlog-flow issue: it affects planning inputs, dependency clarity, and the System Demo. A single agreed rule across the ART's POs is more durable than a bilateral fix.
2. In parallel, the PM's product-management lead, framed as 'we need a shared working agreement for the ART', not 'she is overstepping'. Bring a one-page proposal: PM owns features and feature-level acceptance criteria; PO owns stories and story-level criteria; changes arrive as requests; both attend PO sync.
3. Business Owner involvement only if PI objectives or delivered value are genuinely at risk.

Two traps: going straight over her head after a single feature request, which turns an ambiguity into a relationship problem; and absorbing it silently until the team stops trusting your decisions. The second is the more common failure because it feels like being a good colleague in the short term.

Keep the escalation neutral in form: what happened, what you tried, what rule you propose. Escalations that read as complaints get resolved as complaints; escalations that propose a rule get resolved as rules.