AI User Story Template: Write AI Feature Requirements That Engineers Can Actually Ship
TL;DR
Standard user stories don't work for AI features. You can't write 'the AI will understand user intent' as an acceptance criterion — that's not testable. AI stories require input/output specification, performance thresholds, edge case behavior, and fallback requirements that traditional story templates never include. This template gives engineering what they actually need to build.
Why Standard User Stories Break for AI
Standard story format ('As a user, I want X so that Y') captures the user intent but not the system behavior. For deterministic features, the behavior is implicit in the design. For AI features, the behavior must be explicitly specified — because the model's behavior under edge cases, errors, and uncertainty is where most of the product decisions live.
Gap: No performance threshold
Consequence: Engineering builds a classifier. PM says 'it needs to be accurate.' What does accurate mean? 80%? 95%? Is 88% acceptable? Without a threshold, there's no clear definition of done — and the feature ships when the team runs out of time, not when it works.
Gap: No edge case specification
Consequence: The AI works great on typical inputs. But what happens when the input is very short, very long, in an unexpected language, or deliberately adversarial? Without edge case specs, edge case behavior is whatever the model does by default — which is often wrong.
Gap: No fallback behavior
Consequence: The AI returns a low-confidence result or an error. What should the product do? Show nothing? Show a degraded version? Route to human review? Without a specified fallback, engineering makes this decision in the absence of the PM — usually by shipping nothing.
Gap: No evaluation criteria
Consequence: How do you know the story is done? 'Users are happy with it' is not testable before launch. Without defined evaluation criteria, you can't run a structured test, can't write an automated regression test, and can't make a go/no-go launch decision with confidence.
The AI User Story Format
Story header (standard)
As a [user persona], I want [AI capability] so that [user outcome]. Example: As a support agent, I want the AI to suggest a response category for incoming tickets so that I can route them faster without reading every ticket in detail.
Inputs (required)
What data does the AI receive? Specify format, expected range, and constraints. Example: Ticket text (1–2000 characters), optional subject line, customer account tier (free/paid/enterprise). Input constraints inform model selection and prompt design.
Expected outputs (required)
What should the AI return? Specify exact format and field types. Example: JSON with fields: category (enum: billing/technical/feature-request/general), confidence (float 0–1), reasoning (string, max 200 chars). Concrete output specs prevent the 'what should this return?' conversation during sprint.
Example input/output pairs (minimum 3)
Provide real examples from your domain. These become test cases and help engineers understand the model's expected behavior better than any prose description. Include at least one easy case, one hard case, and one edge case.
Performance requirements
Minimum acceptable accuracy/performance metric and how it will be measured. Example: Category accuracy ≥ 88% on a held-out test set of 500 tickets, measured before sprint completion and again 2 weeks post-launch.
Specifying Model Behavior for Edge Cases
Edge case: Low confidence output
When confidence < [threshold], the UI should display [behavior]. Options: show the prediction with a caveat ('Suggested — please verify'), hide the AI output entirely, route to human review queue. You must specify which threshold triggers each behavior.
Edge case: Empty or very short input
If the input is fewer than [N] characters, [behavior]. AI models often hallucinate or return nonsense for insufficient input. Specifying minimum input requirements prevents shipping a feature that fails on a common edge case.
Edge case: Out-of-domain input
If the input is in a language the model wasn't designed for, contains only numbers/codes, or is clearly not within scope, [behavior]. This is the 'unknown category' problem — the model will assign something even when the right answer is 'I don't know.'
Edge case: Model API failure or timeout
If the AI call fails or exceeds [latency threshold], the product should [behavior]. Options: show a loading state for [N] seconds then degrade gracefully, use a cached result, show a default. Specify the timeout value and what happens after it.
Write AI Requirements That Ship in the Masterclass
AI feature specification, engineering partnership, and delivery excellence are core curriculum — taught live by a Salesforce Sr. Director PM.
Acceptance Criteria for AI Stories
Performance criterion
Given [test dataset], the model achieves [metric] ≥ [threshold]. Example: Given the 500-ticket held-out test set, the classifier achieves category accuracy ≥ 88% and false positive rate ≤ 5% on the 'billing' category.
Fallback criterion
Given [failure condition], the user sees [specific behavior]. Example: Given a model API timeout after 3 seconds, the ticket routing UI displays the manual routing interface without an AI suggestion.
Safety criterion
Given [adversarial or sensitive input], the model returns [acceptable behavior]. Example: Given a ticket containing only profanity or personally identifiable information, the model returns a 'general' category rather than a specific category with high confidence.
Monitoring criterion
At launch, the following metrics are tracked: [list]. Alerts are configured at: [thresholds]. The sprint is not complete until monitoring is live. This forces PM and engineering to align on what 'working in production' means before shipping.
Definition of Done for AI Features
Performance gate passed
Model achieves the defined accuracy/quality threshold on the held-out evaluation set. This is verified by the PM and ML engineer together — not just reported by the person who built it.
Edge cases explicitly tested
All specified edge cases have been tested and the behavior matches the specification. Any edge cases where behavior deviates are documented and the PM has explicitly accepted the deviation.
Fallback behavior verified
At least one failure mode (API error, low confidence, invalid input) has been tested in staging and the fallback behavior matches the spec.
Monitoring and alerting live
Production monitoring is configured with alert thresholds before the feature is live, not after. The PM knows who receives alerts and what the escalation path is.
Rollback plan documented
There is a written plan for how to disable or revert the AI feature within 30 minutes if a critical issue is discovered post-launch. Rollback should be a button, not a 2-hour engineering operation.
Write AI Requirements That Ship on Time
AI feature specification, story writing, and engineering collaboration are core curriculum in the AI PM Masterclass. Taught by a Salesforce Sr. Director PM.