4.5 AI-Enhanced Retrospectives & Modernizing the Definition of Done

4.5 AI-Enhanced Retrospectives and the Definition of Done

Core principle: Use AI to support inspection and learning, not to judge people or waive quality. The Scrum Team creates useful improvements; Developers remain accountable for the Definition of Done.

---

Sprint Retrospective Purpose

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools, and its Definition of Done. It discusses what went well, what problems occurred and how they were or were not solved. The team identifies the most helpful changes. The most impactful improvements are addressed as soon as possible and may be added to the Sprint Backlog for the next Sprint.

The event concludes the Sprint and is timeboxed to three hours for a one-month Sprint, usually less for shorter Sprints.

Appropriate AI Support

With suitable consent and authorization, AI can cluster observations, compare flow patterns, suggest neutral questions, or draft small experiments. Preserve source and uncertainty. A model may erase minority experience in a summary, misread tone, or infer emotion from language. It cannot guarantee anonymity when detailed combinations can re-identify a person.

The Scrum Master should facilitate direct participation and psychological safety. Avoid individual productivity scores, hidden sentiment analysis, or generated blame. Team-level data can still be sensitive and misleading. People inspect whether a measure reflects the system and can challenge the interpretation.

A good improvement experiment states the observed problem, proposed change, expected signal, guardrails, owner, and review point. AI can draft alternatives; the Scrum Team chooses and learns from actual outcomes.

Definition of Done Fundamentals

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.

If organizational standards define a Definition of Done, Scrum Teams must follow it as a minimum. If not, the Scrum Team creates one appropriate for the product. Developers are required to conform to it. Multiple Scrum Teams working on one product must mutually define and comply with the same Definition of Done.

Work that does not meet the Definition of Done cannot be released or presented at the Sprint Review. It returns to the Product Backlog for future consideration. A Product Owner cannot waive that rule by “accepting” a partially completed item.

AI Impact Expectations

Scrum.org's curated article on AI and the Definition of Done begins with six existing categories teams may consider:

1. Process expectations;
2. Technical quality;
3. Delivery readiness;
4. Industry obligations;
5. Organizational standards;
6. Non-functional requirements.

It then adds AI Impact Expectations. Applicable examples include bias and fairness evaluation, human oversight on request, secure handling of prompts and data, transparency or explainability, toxicity checks, regulatory requirements, and secure prompt storage. These are categories and examples, not a universal mandatory checklist.

Make Criteria Product- and Risk-Specific

A conversational product giving refund guidance may need a versioned evaluation set of representative and adversarial cases, source-grounded response checks, prompt-injection tests, monitoring, and a safe escalation path. A deterministic parser assisted by AI may need different controls. Thresholds, sample size, subgroup measures, review method, and frequency come from product risk and evidence—not generic values such as 85%, 95%, or 0.88.

A “golden set” is one useful evaluation practice, not a Scrum artifact. It can become stale, encode gaps, or overfit if reused without challenge. Version it, document provenance, include counterexamples and edge cases, protect personal data, and complement it with other testing and operational monitoring.

An LLM judge can help triage output but is not a sole oracle. Compare with human-labeled examples, deterministic assertions, actual product behavior, and independent checks.

AI-Assisted Code

The Definition of Done should address the risk of the product, not author identity alone. Compilers, tests, static analysis, dependency controls, security review, and peer review may all apply. Some low-risk generated code may be adequately checked through automated and human controls already in the workflow; high-risk changes require stronger review. “Every AI line must receive a special manual review” is not a Scrum rule, while blind acceptance is irresponsible.

Retrospective-to-DoD Adaptation

If the Retrospective reveals a repeated AI failure, inspect whether the Definition of Done lacks an appropriate product quality measure. Add a measurable criterion only when the team can perform it consistently and it improves transparency. Do not create a giant checklist that no one can satisfy. Adapt evaluation as the model, product, users, and threats change.