The 30% mandate and the 120-point forecast

Four distinct problems, with different owners.

1. Capacity is being allocated outside the Product Owner's ordering and the team's self-management. A 20% reservation imposed at a town hall means the Sprint Backlog is now partly written by someone who is not doing the work. The team can still self-manage, but only if the reservation becomes an ordered Product Backlog item with a Sprint Goal it can actually serve - not a slice of capacity removed from every Sprint regardless of what is most valuable.
2. A numeric target has replaced a hypothesis. '30% by Q3' is not falsifiable as stated: 30% of what, measured how, against which baseline, controlling for what else changed? A target with no measurement definition reliably produces activity that looks like the target.
3. The forecast has been converted into a commitment. A tool-generated estimate of 120 points, accepted upward, turns an empirical forecast into a promise made by people who did not make it. That is the opposite of the transparency Scrum depends on.
4. A risk with no owner. Legal has not concluded. Teams are therefore each making their own guess about customer data - which is exactly why usage is bimodal. Unclear rules produce both recklessness and paralysis.

Next two weeks:

• With the Product Owner: get the 20% onto the Product Backlog as an explicit, ordered item with a stated question it answers and a written kill criterion. Capacity is then allocated by the person accountable for value, visibly.
• Surface the legal gap as an impediment with a named owner and a date. Bring it to the director as a delivery risk, not a compliance complaint.
• Replace 'AI-assisted hours' with measures that mean something: cycle time, items reaching Done, escaped defects, review load. Hours logged measures enthusiasm, not productivity.
• Make AI use visible in the Definition of Done so the Sprint Review shows what was actually produced and verified.

Explain what the number actually is. A generative model has no access to your team's capacity, its history, its codebase, its dependencies or its interruptions. Asked for an estimate, it produces plausible text conditioned on the prompt - usually anchored to whatever number or framing the prompt contained. It is a prompt-shaped guess, and the fact that it reads fluently is a property of the writing, not evidence about the work.

Then give the director something better, not nothing. Offer an empirical forecast the team can stand behind:

• Plot items reaching Done per Sprint for the last six Sprints. Use the range - for example, between 38 and 52 items - as the forecast, with the assumptions stated.
• State the confidence and the conditions: this holds if the team is not pulled onto unplanned work and if the review queue is reduced.
• Explain the cone of uncertainty widening with horizon: a confident number for next Sprint, a range for next quarter, and honest doubt beyond that.

Name the anchoring risk out loud. Once 120 is on a slide, it becomes the expectation, and every subsequent conversation is about the gap to 120 rather than about what is actually achievable. That is not a reason to hide the data; it is a reason to publish the right data first.

Also offer the experiment frame the director is actually looking for. A 30% target becomes useful when written as: 'we believe assistant use reduces time from started to Done; we will measure cycle time on comparable items for two Sprints; we will stop if cycle time does not improve or if escaped defects rise.' That gives the director a real answer with a date attached, and gives the team something it can influence.

Use the levers a Scrum Master actually has: transparency, evidence, relationships and framing.

• Make reality visible rather than argued. Publish the data the teams already generate - items reaching Done, cycle time, review queue depth, escaped defects, and what happened to them after AI adoption. An argument about whether the tool helps is unwinnable; a two-Sprint chart of cycle time is hard to dismiss and is also honest when it shows a gain.
• Work through the Product Owner, not around them. The 20% question is a value-ordering question, and the Product Owner is the person accountable for ordering. Coach the PO to bring the trade-off to the director themselves - a PO asking for the experiment to be framed as a backlog item is a different conversation from a Scrum Master objecting.
• Convert complaints into owned risks. For Legal: 'who owns the decision on customer data, and by when?' For the director: 'if this lands and has to be rolled back, what does that cost?' Executives respond to owned risk far better than to unease.
• Propose a small bet with a pre-agreed kill criterion. It gives the initiative momentum and gives the teams a protected way to stop something that is not working. Being the person with a viable next step beats being the person who says no.
• Use the Sprint Review as the forum. Show a real Increment and the real measures; invite the director. Empiricism works best when the sceptic is in the room looking at the same artefact.
• Escalate once, factually, if a team is being asked to breach the DoD or a legal constraint. State what you observed, the risk, and who is accepting it. Your accountability is to make it visible and owned; not to win.