AI-Focused Retrospectives for Team AI Working Agreements
Use an AI retrospective to turn scattered tool use into clear team rules, safer workflows, and better human review habits.
AI is already part of daily work for many software and product teams. It drafts notes, explains code, summarizes research, suggests tests, and helps people get past blank-page work.
That does not mean the team has a shared way of using it.
One person may use AI to draft customer-facing copy. Another may avoid it because the rules are unclear. Someone else may paste sensitive context into a tool without noticing the risk. A useful prompt pattern might help one person, but never spread to the rest of the team.
An AI-focused retrospective turns those scattered habits into a practical team AI working agreement.
When to run an AI retrospective
Run one when AI use is growing faster than the team’s norms. That can happen after a new tool rollout, a policy change, a quality issue, or a sprint where AI clearly changed how work moved.
The goal is not to debate AI in general. The goal is to decide how this team will use AI in this workflow, with clear human ownership.
Start with real examples
Do not open with “What do we think about AI?” That invites abstract opinions. Ask for recent examples from actual work.
Where did AI save time this month?Where did AI produce something we had to correct?Where did AI make review harder?Where are we unsure whether AI use is allowed?What AI use case should more people on this team know about?
Group the answers into three buckets: encouraged uses, guardrailed uses, and off-limits uses. This keeps the conversation grounded in behavior instead of preference.
Clarify human review
The most important AI working agreement is usually simple: AI can assist, but humans still own the outcome.
Make that ownership explicit. Decide where AI may draft, summarize, transform, suggest, or explore, then define who reviews the work before it ships.
AI can draft release notes, but a human reviews factual accuracy before publishing.AI can suggest test cases, but QA owns final coverage and risk assessment.AI can explain unfamiliar code, but engineers verify behavior in the codebase.AI must not receive secrets, private keys, or unapproved customer data.
Write the team AI working agreement
End the retro with a short agreement people can actually use. Five to seven rules is enough. Longer policies are harder to remember and easier to ignore.
Encouraged uses:where AI should become normal.Guardrailed uses:where AI is allowed with review or approved tools.Prohibited uses:where AI should not be used by this team.Review expectations:who checks accuracy, privacy, quality, and decisions.Sharing habits:how the team shares prompts and lessons.Next review date:when the team revisits the rules.
Make the agreement visible
An AI retro that ends with “we should use AI better” will not change much. Turn the agreement into small, owned actions.
Example: a QA team agrees AI is useful for first-pass test ideas, but humans still own risk analysis, coverage, and final test design.
Track whether the agreement improves the workflow: fewer review loops, clearer handoffs, safer use of internal context, and more confidence from people who were unsure what was allowed.
Use HeyRetro to build custom AI-retro prompts, collect anonymous input, and turn agreement updates into action items. Start from the template library, then adapt the columns for opportunities, risks, standards, and experiments.
If the team needs a stronger action habit first, read how to make retro actions stick.