by Stefan Wolpers|FeaturedAgile and ScrumAgile Transition
TL;DR: The AI Definition of Done
Your team has a Definition of Done for a product increment. It has none for the 20-plus AI-supported outputs that leave the team each week: status reports, stakeholder emails, release notes, and updates for the C-level. Each one carries your team’s name. “I know quality when I see it” is the standard most teams actually run by, and you cannot audit it, teach it to a new colleague, or defend it when a claim turns out to be wrong. The AI Definition of Done fixes that with one page per task class, agreed by the team, before the output ships.
Your Claude Pro subscription hits limits faster than it did in January, as Anthropic quietly re-priced the ceiling, and every AI provider is rationing compute. If you keep working with Claude the way you did six months ago, you are in for a rude awakening. This article gives you four principles that explain how Token Economics actually works, so you can stop accepting the black box and start using your budget deliberately.
by Stefan Wolpers|FeaturedAgile and ScrumAgile Transition
Using AI at Work Does Not Mean You Understand It
Many agile practitioners use ChatGPT at work. That does not mean they understand AI well enough to trust your own judgment. The problem is not that agile practitioners ignore AI. The problem is that many already use it confidently without knowing where their judgment breaks down. The free AI4Agile Foundational Assessment measures precisely this skill gap. (Download your access file below.)
The assessment comprises 40 scenario-based questions. It does not ask for definitions, but puts you into situations that agile coaches, product managers, and Scrum Masters face every week: weak prompting producing generic output, misleading data analysis, questionable agent output, and, possibly, organizational pressure to treat AI output as “good enough” to go with it.
Most people who use AI do not fail because they lack knowledge, but because they cannot distinguish between plausible outputs and trustworthy judgment. But see for yourself!
by Stefan Wolpers|FeaturedAgile and ScrumAgile Transition
TL;DR: The A3 Handoff Canvas
The A3 Framework helps you decide whether AI should touch a task (Assist, Automate, Avoid). The A3 Handoff Canvas covers what teams often skip: how to run the handoff without losing quality or accountability. It is a six-part workflow contract for recurring AI use: task splitting, inputs, outputs, validation, failure response, and record-keeping. If you cannot write one part down, that is where errors and excuses will enter.
The Handoff Canvas closes a gap in a useful pattern: from an unstructured prompt to applying the A3 framework to document decisions with the A3 Handoff Canvas, to creating transferable Skills, potentially leading to building agents.
by Stefan Wolpers|FeaturedAgile and ScrumAgile Transition
TL; DR: The A3 Framework
The A3 Framework categorizes AI delegation before you prompt: Assist (AI drafts, you actively review and decide), Automate (AI executes under explicit rules and audit cadences), or Avoid (stays entirely human when failure would damage trust or relationships). Most AI training teaches better prompting. The A3 Framework teaches the prior question: Should you be prompting at all? Categorize first, then prompt.
by Stefan Wolpers|FeaturedAgile and ScrumAgile Transition
TL; DR: Why the Brand Failed While the Ideas Won
Your LinkedIn feed is full of it: Agile is dead. They’re right. And, at the same time, they’re entirely wrong.
The word is dead. The brand is almost toxic in many circles; check the usual subreddits. But the principles? They’re spreading faster than ever. They just dropped the name that became synonymous with consultants, certifications, transformation failures, and the enforcement of rituals.
You all know organizations that loudly rejected “Agile” and now quietly practice its core ideas more effectively than any companies running certified transformation programs. The brand failed. The ideas won.
TL; DR: The Scrum Master Interview Guide to Identify Genuine Scrum Masters
In this comprehensive Scrum Master Interview guide, we delve into 97 critical questions that can help distinguish genuine Scrum Masters from pretenders during interviews. We designed this selection to evaluate the candidates’ theoretical knowledge, practical experience, and ability to apply general Scrum and “Agile “principles effectively in real-world scenarios—as outlined in the Scrum Guide or the Agile Manifesto. Ideal for hiring managers, HR professionals, and future Scrum teammates, this guide provides a toolkit to ensure that your next Scrum Master hire is truly qualified, enhancing your team’s agility and productivity.
If you are a Scrum Master currently looking for a new position, please check out the “Preparing for Your Scrum Master Interview as a Candidate” section below.
So far, this Scrum Master interview guide has been downloaded more than 25,000 times.
TL; DR: 82 Product Owner Interview Questions to Avoid Imposters
If you are looking to fill a position for a Product Owner in your organization, you may find the following 82 interview questions useful to identify the right candidate. They are derived from my sixteen years of practical experience with XP and Scrum, serving both as Product Owner and Scrum Master and interviewing dozens of Product Owner candidates on behalf of my clients.
So far, this Product Owner interview guide has been downloaded more than 10,000 times.
TL; DR: Scrum Training Classes, Liberating Structures Workshops, and Events
Age-of-Product.com’s parent company — Berlin Product People GmbH — offers Scrum training classes authorized by Scrum.org, Liberating Structures workshops, and hybrid training of Professional Scrum and Liberating Structures. The training classes are offered both in English and German.
Check out the upcoming timetable of training classes, workshops, meetups, and other events below and join your peers.
You moved your routine AI work to a cheaper model, so you think the cost question is handled; however, often, that is not the case. The decision lives in one person’s head and produces nothing that the person accountable for the invoices can read. Worse, it is an architectural choice nobody documented. The AI Routing Policy is the missing artifact of Stage 2 of the Delegation Lifecycle: it records which execution path, from a cheaper model to a frontier model to plain code, handles each class of work, what counts as good enough output to meet the AI Definition of Done, and who owns the call. The skill it needs to work is one you already have: You write acceptance criteria.
Thesis: An AI routing policy is not about picking a cheaper model at the moment of executing an AI task. It is a written, repeatable team decision that assigns each task class to the cheapest sufficient execution path: a model, human review, deterministic code, or no automation. Paired with a minimal routing log, it creates the spend-by-task-class record that your finance team will eventually request. You can draft the first three lines in twenty minutes.
🎓 🇬🇧 The AI4Agile Online Course v3 — July 20, 2026, at $149 — Join the Waitlist
Sooner or later, a CFO will ask what your AI use actually returns. “It saves me time” will not survive that meeting.
The first wave of AI adoption rewarded practitioners who learned to prompt. That skill still matters, and this course still teaches it. The second wave rewards something rarer: people who can turn individual AI use into knowledge that survives departures, spend that can be explained and steered, and output that organizations can trust. That work is process design and change management. You have been doing both for years, on harder problems than this.
EXCLUSIVE: The new A3 Delegation Lifecycle System with all Templates to make sense of delegating work to AI models.
✅ 16+ hours of self-paced video modules ✅ A cohort-hardened, proven course design ✅ Learn to 10x your effectiveness with AI; your stakeholder will be grateful ✅ The AI Delegation Lifecycle System, including the A3 Framework, A3 Handoff Canvas, AI Definition of Done, and AI Delegation Audit as working handouts ✅ Apply AI to classic use cases of “Agile” ✅ The complete MegaBrain.io case package across both acts ✅ All texts, slides, prompts, graphics; you name it ✅ Access custom GPTs, including the “Scrum Anti-Patterns Guide GTP” ✅ Guaranteed: Lifetime access to v3 ✅ AI4Agile Foundation Certificate: 40 questions in 45 minutes.
👉 Please note: The course will be available for $149 from July 20 to 27, 2026! (After that, $249.) 👈
Not every company has a board, but every company has a person in the chief financial officer seat: a controller, a chief accountant, or the owner who signs the invoices. At some point, that person looks at the AI line on the budget and asks a simple question: What does this spend buy, and how would we know it creates a return on investment?
In most teams, the answer is a shrug. Someone switched the weekly status draft to a cheaper model last spring. Someone else left the customer-facing summaries on the frontier model because it “felt safer.” Nobody wrote either decision down. While the AI token expenditure is real, the rationale is folklore.
Why a Cheaper Model Is Not a Policy
The fallacy worth naming first is that switching to the cheaper model solves your cost problem. Most likely, it won’t: a model choice that lives only in habit disappears the day the person who made it changes teams. You may have lowered the bill, but you did not create cost control. You made an undocumented architecture decision with financial consequences, and left no one able to explain it.
What Stage 2 of the AI Delegation Lifecycle Is
In the Delegation Lifecycle, Stage 1 (Decide) uses the A3 Framework to answer whether AI should touch a piece of work at all: Assist, Automate, or Avoid. Stage 2 (Route) answers the next question: which execution path runs the work, and what is good enough for that class of work.
AI routing is not the act of selecting a model while you work. That habit matters, and I covered it for the individual practitioner in an earlier piece on token economics (see Related Articles below). This is the level above the habit: the team standard that survives the individual. A written policy says status drafts run on the mid tier, contract review runs on the frontier tier with human review, and recurring calculations run on plain code, each with a one-line reason.
An AI model tier bundle is more than price. It is a capability, risk, data-handling, and accountability class, and the cheapest option that clears the bar is not always a model. A route is wider than a menu of models: a frontier model, a cheaper model, deterministic code, human-only work, a model plus human review, or no automation at all.
It is the difference between a developer who happens to write good code and a team that has a Definition of Done. One depends on the person. The other depends on the agreement.
The load-bearing idea in an AI routing decision is sufficiency: what does good enough mean for this class of work? Paying for a frontier model on a task that only needs a decent first draft is a waste. A cheap model on a task that goes to a regulator is a different kind of waste, the kind that appears in an incident review.
You write this standard the same way you write acceptance criteria for a Product Backlog item. The standard is not “the best the model can do.” It is whether the output meets the stated conditions that a named person can check:
For a weekly internal update: traceable to the source board, under 300 words, no invented status.
For an external compliance summary: every claim sourced, reviewed by a human before it leaves, zero tolerance for a feature that does not exist.
It is the same discipline you apply when you refuse a story without testable acceptance criteria.
The friction appears in three predictable places:
Teams argue quality in the abstract and never write the criterion, so every task defaults to the most capable model, and the bill climbs.
Or they name the route but skip the escalation trigger, so nobody knows when a task is allowed to move up to a more expensive one.
Or they write the whole policy and name no owner, so nobody maintains it, the same way nobody maintains an un-owned automation.
An AI routing policy without an owner is a suggestion.
The Route Most Teams Forget: No Model at All
Routing to a cheaper model is the first lever everyone reaches for. It is also the smallest one. The smarter move is to ask whether the task needs a model every time, or only once.
Packy McCormick and Markie Wagner make the case in their June 2026 essay: “Thinking is expensive but happens rarely. Doing is cheap and happens forever.” Their punchline is shorter: “Because you know what’s cheaper than Chinese models? Code.” (Not Boring, June 10, 2026.) A recurring calculation, a format conversion, or a status roll-up with fixed rules does not need probabilistic judgment on every run. It needs professional judgment once, to design the deterministic path, and then plain code that produces the same output every time.
For a non-coding practitioner, this is still a routing decision you can make, even if you hand the build to a developer or have a model write the script one time. The leadership question is not “which model is cheapest.” It is: does this task need probabilistic judgment every time, or only once to design the path? An AI routing policy that offers only cheap, mid, and frontier models stays trapped in the model vendors’ cost logic. Add two more routes, deterministic code, and no automation at all, and the policy becomes an operating-model decision.
AI Routing Is Where a Team Makes Its Trade-Offs Explicit
Finance is the pressure that makes routing visible, but cost is not the only variable a route balances. Optimize for one alone, and another gives way:
Cheapest model everywhere: the bill drops, and quality can collapse on the work that mattered.
Frontier model everywhere: quality holds, and cost discipline collapses.
Human review everywhere: risk falls, and throughput collapses.
Agentic workflow everywhere: autonomy rises, and repeatability collapses.
Deterministic code everywhere: cost falls, and adaptability collapses the moment the rules change.
A route is where a team makes those trade-offs deliberately rather than by accident. That is the difference between using AI and governing it.
Return on Tokens, and Why Task-Class Attribution Matters
Once the routes exist, you need a way to determine whether each route covers its cost. McCormick and Wagner gave that discipline a name: Return on Tokens (ROT), with a plain formula:
Return on Tokens = (Value of Output − Cost of Tokens) / Cost of Tokens × 100.
The formula is the easy part. The operational implication is the hard part: you cannot improve Return on Tokens if you do not know which task class consumed them. The same essay reports the pattern behind the urgency: Fortune 500 leaders admitting they had committed to enormous token spend with no idea what they were getting back.
That is the issue for most readers. On a Claude Pro or Max subscription, you cannot see per-task token cost; the meter moves, and you cannot trace it to a workflow. The discipline still matters because you build it before the subsidy ends, so you are not the one scrambling when flat-rate access narrows further.
If your work runs through the API, you already pay per token, and Return on Tokens is a number you can compute today for each task class against your AI routing policy. The subscriber is rehearsing for metered reality, while the API user already lives in it.
What the Numbers Make Finance Ask
The Ramp Economics Lab publishes U.S. companies’ AI spending per employee, based on aggregated card and bill-pay data from more than 70,000 businesses. In June 2026, the median firm spent $11.38 per employee per month, about one enterprise subscription seat. The top 10% spent $611. The top 1% spent $7,449. (Ramp Economics Lab, June 10, 2026.) That data is spend-side only: it shows what companies pay, not what the spend returns, which is the gap an AI routing policy and a log are meant to close.
Finance rarely worries about one subscription seat. Finance starts asking harder questions when flat-rate experimentation turns into metered API usage, agentic workflows, departmental duplication, and invoices no team can trace back to work. At that point, CFOs want to learn: what runs on frontier models versus cheaper alternatives, by task class, and why. That demand is the AI routing policy, written from the outside in.
A Routing Policy You Can Copy
Here is what three lines look like. Take one task class per row and fill the five columns:
Task class
Default route
Sufficiency criterion
Escalation trigger
Owner
Weekly internal status draft
Mid-tier model
Traceable to the board, under 300 words, no invented status
Missing data, any customer-facing claim, unresolved risk
Workflow owner
Customer-facing roadmap summary
Frontier model plus human review
Every claim sourced, no uncommitted feature shown as committed
Enterprise customer, legal or security claim
Product Owner
Recurring metrics calculation
Deterministic script, no model
Same input produces same output, test cases pass
Metric definition changes
Product Analyst
That is the structure of the record finance wants. It is not the record itself yet.
The Record Finance Can Finally Read
An AI routing policy defines the record’s structure; minimal routing logs turn that structure into evidence:
Without the log, the policy explains intent.
With the log, it explains expenditures.
The log adds a few fields to each entry: the actual route used, the escalation reason when a task is moved up, a token or cost estimate, the reviewer, and an outcome signal so the policy optimizes for value, not just the lowest bill.
Skip the log, and the policy is governance theater: well written, and accountable to no invoice. Keep the log, and the same meeting that routes the work leaves the trail that finance and procurement ask for later, with no separate report. That is the real economy of the Delegation Lifecycle: the operational artifacts answer the governance questions, once you spend the small effort to record what they decide.
What to Do Before Your Next Planning Session
Do not write a company-wide AI routing policy this week. Take one recurring AI task, the one whose cost or risk you understand least, and fill one row of the table above: the route it runs now, what good enough means in testable terms, the escalation trigger, and the owner. Add one more column, the actual route used last time, and you have started the log. You will probably find the route was never decided, and the standard was never written. That single gap is the case for the policy.
Conclusion
Acceptance criteria keep a team honest about what “done” means before work starts. An AI Routing Policy extends that habit to how the work gets done: which path, against what standard, with what escalation trigger, and where it is recorded. The skill is not new, only the object is.
I have added the AI Routing Policy and a Return on Tokens exercise to version 3 of the AI4Agile Online Course, scheduled for July 20, 2026. The exercise uses June 2026 market data and a worked task portfolio, so participants practice routing real work instead of debating model preferences in the abstract.
When someone in your organization asks what your AI spend buys, will you have a policy and a log to point to, or a shrug?
Key Questions This Article Answers
What Is an AI Routing Policy?
A Routing Policy is a written, repeatable team decision that assigns each class of AI-assisted work to the cheapest sufficient execution path, against a stated sufficiency standard, with a named owner. It is the artifact of Stage 2 (Route) of the AI Delegation Lifecycle. The skill it needs is the one you already use to write acceptance criteria.
What Are the Routing Options?
A route is wider than a menu of models. The options are a frontier model, a cheaper model, deterministic code, human-only work, a model plus human review, or no automation at all. A policy that routes only among model tiers stays trapped in the model vendors’ cost logic. The smarter question is whether the task needs probabilistic judgment every time, or only once to design a deterministic path.
Does an AI Routing Policy Give Finance a Spend Record?
Not on its own. A Routing Policy defines the record structure: task class, route, sufficiency reason, escalation trigger, and owner. A minimal routing log turns that structure into evidence by capturing the actual route used, the escalation reason, a cost estimate, the reviewer, and an outcome signal. Without the log, the policy explains intent. With the log, it explains the spend.
What Is Return on Tokens?
Return on Tokens is a measure proposed by Packy McCormick and Markie Wagner in June 2026: (Value of Output − Cost of Tokens) / Cost of Tokens × 100. The formula is the easy part. The operational implication is more difficult: you cannot improve Return on Tokens without knowing which task class consumed them, which is what an AI routing policy and its log make possible.
Learn more about the AI Routing Policy with our AI and Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:
You can book your seat for the training directly by following the corresponding links to the ticket shop. If your organization’s procurement process requires a different purchasing approach, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn More about the AI Routing Policy — Join the 20,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
TL; DR: AI Confidence Theater — Food for Agile Thought #551
Welcome to the 551st edition of the Food for Agile Thought newsletter, shared with 35,473 peers. This week, Elena Verna calls out AI confidence theater and asks teams to show real workflows, which pairs well with Teresa Torres and Petra Wille’s advice to start AI adoption with one messy to-do item. Also, Janna Bastow brings the same discipline to alignment meetings: clarify decisions before vague input becomes commitment. Anthropic frames Fable 5’s return as governance, while Alberto Romero questions the safety bargain, and Mike Cohn redirects failed Agile blame toward broken conditions.
Next, Aakash Gupta and Shubham Saboo treat PM work like code, while Hamel Husain extends that discipline to AI evaluation: track changes, show provenance, and make review paths obvious, and Tomasz Tunguz adds the cost pressure that will force selective adoption. Joost Minnaar reminds teams that rituals without shared power rot into theater, and Anthropic frames Claude Fable 5 as a teammate needing clearer boundaries.
Lastly, Ethan Mollick sees AI work shifting toward agent management, while Peter Yang expects model portfolios to reshape software economics. Charity Majors argues that leaders must support learning rather than demand unpaid adaptation, and Gergely Orosz reminds us that reinvention beats nostalgia. Finally, Abraham Thomas ties lasting progress to data quality that delivers real business outcomes by matching fitness for purpose with measurable value rather than relying solely on checklists.
Scrum teams inspect how the last Sprint went during the Retrospective. They are much less likely to inspect the work they have handed to AI, because no meeting on the calendar owns it. That gap is where a working AI automation quietly turns into risk: it keeps producing fluent, on-brand output long after the decision to trust it has expired. The AI Delegation Audit closes the gap by leveraging the facilitation skills teams already use in a Retrospective.
Thesis: The Delegation Audit is the missing inspection cadence for delegated AI work. It checks four things: whether the work still meets the standard, whether the model still fits the task, whether the team can still stop the automation, and whether reviewed assistance has quietly become unreviewed automation. You can try it on one workflow in fifteen minutes.
🎓 🇬🇧 The AI4Agile Online Course v3 — July 20, 2026, at $149 — Join the Waitlist
Sooner or later, a CFO will ask what your AI use actually returns. “It saves me time” will not survive that meeting.
The first wave of AI adoption rewarded practitioners who learned to prompt. That skill still matters, and this course still teaches it. The second wave rewards something rarer: people who can turn individual AI use into knowledge that survives departures, spend that can be explained and steered, and output that organizations can trust. That work is process design and change management. You have been doing both for years, on harder problems than this.
EXCLUSIVE: The new A3 Delegation Lifecycle System with all Templates to make sense of delegating work to AI models.
✅ 16+ hours of self-paced video modules ✅ A cohort-hardened, proven course design ✅ Learn to 10x your effectiveness with AI; your stakeholder will be grateful ✅ The AI Delegation Lifecycle System, including the A3 Framework, A3 Handoff Canvas, AI Definition of Done, and AI Delegation Audit as working handouts ✅ Apply AI to classic use cases of “Agile” ✅ The complete MegaBrain.io case package across both acts ✅ All texts, slides, prompts, graphics; you name it ✅ Access custom GPTs, including the “Scrum Anti-Patterns Guide GTP” ✅ Guaranteed: Lifetime access to v3 ✅ AI4Agile Foundation Certificate: 40 questions in 45 minutes.
👉 Please note: The course will be available for $149 from July 20 to 27, 2026! (After that, $249.) 👈
A product team automates its Friday stakeholder update in March. The setup is careful: the model drafts from the Jira board, the workflow owner reviews the draft, and it ships. For three months it works. In June, the same automation tells an enterprise prospect that a security feature is in production.
No application code changed, and nobody touched the prompt. But the system around the automation had shifted: a descoped feature, a stale ticket title that survived in the product backlog, and a change in model behavior combined into a false update. The dangerous part was not a visible failure: the automation kept producing fluent, plausible, on-brand updates, which is exactly what made the degradation hard to notice.
That points to the belief worth naming first: a workflow that still produces output is assumed to be still fully functioning. A working automation is not evidence that the delegation behind it is still valid, and validating it once, at setup, is not the same as keeping it valid.
What the Delegation Audit Is
The Delegation Audit of the A3 Framework borrows the facilitation pattern of a Retrospective, not the Scrum event itself. Instead of how the team worked, it examines how the team’s AI delegations are holding up: 45 to 60 minutes, monthly or every other Sprint, with a named owner and a slot on the calendar.
In the A3 Framework, this is what the Automate category has always required. The moment you trust work to run with little or no human review, you owe it explicit rules and a recurring audit. Most teams adopt the rules and skip the audit because no one owns it. The Delegation Audit is that meeting, and it is the Inspect step of the AI Delegation Lifecycle.
The name is deliberate: nobody in finance, security, or operations needs an agile glossary to understand what a delegation audit is or why a team runs one. The practice underneath is familiar: gather data, surface what changed, turn findings into decisions, and leave with owners.
Each check inspects one way a delegation degrades after it goes live:
Output and source drift: Does the work still meet its AI Definition of Done, and are the inputs still fit for use? Pull three recent outputs per workflow and trace each one back to its sources. Model updates change output quality in both directions without notice, and the inputs move along with them: stale records, changed permissions, and archived data that the model cannot tell from current facts. A polished summary built on stale data is still a failed delegation.
Model fit: Is the assigned model still the right one? Look in both directions: a cheaper tier that no longer meets the standard, and a frontier model burning budget on work that a mid-tier now handles. The test is whether the model is sufficient for this task at this risk level, not whether it is the most capable one available. If your team runs a routing policy, this check feeds into it, and the cost side has its own treatment in token economics.
Reversibility: Could you stop each automation today? Test the stop rules from your handoff: who pulls the plug, how fast, and whether that person still works here. An automation without a reachable owner is not delegated; it is abandoned, now posing a risk.
Category creep: Which Assist work has become unreviewed Automate? Watch for the tell: review time per output trending toward zero. When a human approves a draft in 4 seconds, that is not review, and the work changed its A3 category without anyone deciding. Name it, then choose: promote it to Automate properly, with rules and a stop rule, or restore genuine review.
Run It Like a Retrospective
The agenda fits 60 minutes and will feel familiar:
Data walk (10 min): Put the delegation inventory on the wall: every automated and assisted workflow, its A3 category, its model tier, its last audit date. Add usage or spend data if you have it. Look first, discuss later.
Run the four checks in pairs (20 min): Assign workflows to pairs. Each pair runs all four checks on its workflows and marks each finding pass, drift, or fail.
Re-classify (15 min): Walk through the findings. Every drift or fail gets a decision: change the A3 category, change the tier, update the AI Definition of Done, fix the stop rule, or retire the delegation. Retiring an automation that no longer earns its audit cost is a successful outcome of the meeting.
Decisions and owners (10 min): Each decision gets a name and a date. A finding without an owner is one you will rediscover next time; don’t create waste.
Close the record (5 min): Update the log: what moved, why, and who decided.
Why Inspection Stopped Being Optional
Two forces make a standing audit necessary now:
The first is the models: they update on the vendor’s schedule, not yours. A change to how a model summarizes, refuses, or formats can move output quality with no signal on your side. An automation you validated once is running on assumptions that have quietly expired.
The second is accountability: NIST organizes AI risk management around four functions: govern, map, measure, and manage. Inspection is the measure-and-manage half, and a team that only governs and maps has stopped before the work becomes operational. Set-and-forget is the default, and it compounds unseen until a drifted output becomes an incident in front of the wrong audience.
The Record You Get for Free
Each audit updates a dated log: workflow, owner, model tier, last checked output, drift finding, decision, and follow-up date. Stack those logs, and you have an inspection trail: evidence that your team’s AI adoption is controlled rather than assumed. When a stakeholder, for example, a prospect’s procurement team, asks how you govern your internal AI use, that trail is half the answer, and you wrote none of it as a separate report. It came out of one recurring meeting.
What to Do in Your Next Retrospective
Do not schedule a new event yet. Take one delegated workflow, the one that would embarrass you most if it drifted, and spend fifteen minutes of your next Retrospective running the four checks on it out loud: output and source, model fit, reversibility, category creep. You will probably find at least one answer that amounts to “nobody has looked since we set this up.” That single finding is the case for putting the audit on the calendar.
Conclusion
A Retrospective keeps a team honest about how it works together. The Delegation Audit extends that same facilitation habit to the work the team handed to a model, where an automation can look healthy long after the decision to trust it has expired.
For readers who want to run this without designing the format from scratch, version 3 of the AI4Agile Online Course, scheduled for release on July 20, 2026, includes the Delegation Audit as a working format, with the inventory, the four checks, and the log ready to run.
When did your team last inspect an automation it trusts, and what would the four checks find if you ran them this week?
Key Questions This Article Answers
What Is a Delegation Audit?
A Delegation Audit is a recurring 45- to 60-minute inspection of a team’s delegated AI work, run monthly or every other Sprint. It checks whether automated and AI-assisted workflows still meet the team’s standard, using the facilitation skills of a Retrospective. It is the Inspect step of the AI Delegation Lifecycle.
What Does a Delegation Audit Check?
Four things:
Output and source drift (Does the work still meet its AI Definition of Done, and are the inputs still trustworthy?),
model fit (Is the assigned model still the right one for the task and its risk level?),
reversibility (Can you stop the automation today?), and
category creep (Has Assist work become unreviewed Automate?).
How Is a Delegation Audit Different From a Retrospective?
Same skill, different subject. A Retrospective inspects how the team worked together. A Delegation Audit inspects how the team’s AI delegations are holding up, then turns each drift finding into a decision with an owner and a date.
Learn more about AI Builders with our AI and Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:
You can book your seat for the training directly by following the corresponding links to the ticket shop. If your organization’s procurement process requires a different purchasing approach, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn More about the AI Delegation Audit — Join the 20,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
TL; DR: Make AI Boring — Food for Agile Thought #550
Welcome to the 550th edition of the Food for Agile Thought newsletter, shared with 35,481 peers. This week, Charity Majors rejects AI purity theater and urges disciplined workplace experiments, just make AI boring again, while Gojko Adzic warns that faster builders without product judgment will ship polished waste. Dave Hora names the organizational traps that keep teams from seeing reality, and Johanna Rothman brings the fix down to flow data and human judgment. Azeem Azhar and colleagues see AI demand rising, but Satya Nadella argues that a durable advantage comes from owning learning itself.
Next, Paweł Huryn moves AI work from prompt craft to agent loops with goals, guardrails, budgets, and independent checks, while Jeff Gothelf argues that AI pilots fail when firms bolt tools onto stale workflows. Joe Hudson adds that emotional clarity now beats knowledge hoarding, and John Cutler names fear, incentives, and executive fantasies as the real bottlenecks. David Burkus brings the pattern back to procrastination, where stress and ambiguity demand clarity without control.
Lastly, Elena Verna pushes experimentation beyond tiny UI tweaks toward larger monetization bets and longer engagement signals, as Zvi Mowshowitz warns AI policy needs calibrated safeguards rather than theater. Deborah Rim Moiso brings the same discipline to facilitation through communities that review real work, and Olivier Wulveryck applies Team Topologies to agentic platforms before shadow IT hardens. Finally, Itamar Gilad grounds the pattern in value, not misleading productivity counts.
TL; DR: AI in Product 2026 — Food for Agile Thought #549
Welcome to the 549th edition of the Food for Agile Thought newsletter, shared with 35,498 peers. This week, Product Circle and Product Institute share the AI in Product 2026 survey show AI coding tools spreading faster than stronger operating models, while Elena Verna sees cheaper software creation opening a Mom-and-Pop SaaS lane for domain experts. Petra Wille counters AI possibilities with accountable product principles, and Sam McVeety and Amir Hormati tackle agent-ready context. Also, Isabel Juniewicz and Ed Zitron question whether increasing hyperscaler spending and the economics of generative AI can sustain the rush, or bubble?
Next, Janna Bastow warns that Slack loses product feedback once channels move on, and Sarah Guo argues that AI shifts durable advantage toward private data, judgment, and trust. Aakash Gupta and Rohan Varma push the logic further, describing AI-native teams that build before they coordinate as the AI way, while Matthew Hodgson adds that enterprises need persistent funding and governance to make AI product operating models work. Then, Gregor Ojstersek shows that top engineering teams are already reshaping structures around AI.
Lastly, Mark Graban warns that tone policing in teams drives bad news underground, while Barry O’Reilly argues that AI raises the premium on visible, codified judgment that requires transparency, not enforced harmony. Johanna Rothman and Sonya Siderova shift the focus from faster tasks to slower systems, where wait times and flow debt shape delivery. Finally, Matteo Tittarelli extends that logic to GTM, where context, skills, orchestration, and integrations must compound across cycles.
