Stories as Delegation Contracts

User Stories Deliver the Three Pillars

The three pillars give you a framework for any prompt. But when you're delegating a feature — not just asking a question — you need a format that packages Scope, Intent, and Structure into a repeatable contract. That's what user stories do.

This isn't a prompting trick — it's how software teams have worked for years. A Product Manager writes a user story. An Engineer uses it as the contract that defines what "done" looks like. The story aligns both sides before anyone starts building. You're applying the exact same pattern here — the only difference is that your delegate is an AI coding assistant instead of a human Engineer.

The format:

As a [type of user], I want [capability], so that [outcome].

Notice that the format starts with a person — not a feature, not a technology, not a screen. That's intentional. Good software is built for people, and the best way to build something valuable is to stay connected to who you're building it for and what they actually need. A user story is a small act of empathy: you step into someone else's shoes and describe the world from their perspective. When you do that — whether you're handing the story to a human or to AI — the thing you build is more likely to be something people actually use.

• "As a" = who you're building for — this grounds every decision in a real person's needs
• "I want" = what to build (Scope — bounded and specific)
• "So that" = why it matters (Intent — the steering wheel that guides AI's judgment calls)

The "so that" clause is especially important. It's the steering wheel — when AI has to make decisions about implementation details (and it will), the "so that" tells it what outcome to optimize for. Without it, AI guesses. With it, AI makes informed tradeoffs.

Acceptance Criteria: Your Definition of Done

A user story tells AI what to build. Acceptance criteria tell both of you when it's done.

The format:

Given [starting condition], when [action happens], then [expected result].

These aren't suggestions — they're your verification checklist. After AI delivers, you walk through each criterion: pass or fail. No guessing, no "it looks okay." Either it meets the criteria or it doesn't.

Example:

As a backcountry skier, I want to submit a field observation so that forecasters and the community have up-to-date information about conditions in my zone.

Given I'm on the observation form, when I select "avalanche" as the observation type, then additional fields appear for aspect, elevation band, and avalanche size.

Given I've filled out all required fields, when I click Submit, then my observation appears in the feed with a timestamp and my zone.

Notice how the acceptance criteria are specific enough that you could hand them to someone who's never seen the project and they'd know exactly what to check. That's the standard — they're a contract between you and your AI delegate.

Here's the pattern that matters: if you can't write acceptance criteria for it, you're not ready to delegate it. The inability to define "done" is your signal that the task needs to be broken down further or explored more before implementation.

The Workflow

The user story plugs into a four-step workflow you'll use throughout the day:

Explore → Plan → Implement → Verify

1. Explore: Before you start building, understand who you're building for. What do your users need? What problems are they trying to solve? What decisions are they making, and what information would help them make better ones? This is the discovery step — you're building enough empathy with your user that you could write a story from their perspective. You can use AI to help: "What does a backcountry skier need to know before heading into avalanche terrain? What are their biggest concerns?"
2. Plan: Write the user story with acceptance criteria — your story IS your plan
3. Implement: Hand the story to AI and let it build
4. Verify: Walk through each acceptance criterion — pass or fail

When verification reveals a problem, the cycle repeats: plan the fix → implement → verify again. The acceptance criteria you wrote in Step 2 are the same checklist you use in Step 4. They do double duty as both spec and test.

Team Activity: Write Your First Delegation Contract

Format: Mob Session Time: ~3 minutes Setup: Gather around one screen. One person controls the keyboard (the driver), while everyone else suggests what to do and what to type (the navigators). Rotate the driver for each activity.

Your team is about to build an Avalanche Observation Network — a platform that serves two types of users. Backcountry skiers submit field observations about what they see in the mountains (snowpack conditions, avalanche sightings, weather, red flags). Avalanche forecasters review those observations each morning to produce daily danger ratings that keep people safe. This is how avalanche centers like the Utah Avalanche Center actually work — community observations are a critical input to the daily forecast.

First, practice the Explore step. Ask your AI coding assistant:

What does a backcountry skier need to know before heading into avalanche terrain? What are their biggest concerns? And what does an avalanche forecaster need from community observations to produce a danger rating?

Spend 60 seconds reading the response. Let it inform which persona you pick and what acceptance criteria you write.

Now pick one of these two user personas and write a user story with 2-3 acceptance criteria. Some options:

• Submission side: "As a backcountry skier, I want to submit a field observation so that..."
• Feed side: "As an avalanche forecaster, I want to browse recent observations filtered by zone so that..."

Add 2-3 Given/When/Then acceptance criteria that define when this feature is done.

Discuss: Notice how the "As a" changes everything — a forecaster browsing observations needs very different things than a skier submitting one. Could you hand this story to someone who's never seen the project and they'd know exactly what to build and how to verify it?

Key Insight

A user story with acceptance criteria is a delegation contract. The story tells AI what to build and why. The criteria tell both of you when it's done. When you can't write the criteria, that's your signal to break the task down further — not to delegate and hope for the best.