Getting Better Results¶
Why This Matters for Your Organization¶
Remember the bottleneck shift from The New Frontier: the hardest problems are no longer about writing code. They are about understanding your users, defining the right outcomes, and reviewing the work. User stories are not a prompting trick. They are a practice that addresses those bottlenecks directly.
The value of AI is not that your teams can deliver 100 features faster. Features are outputs. Outputs are meaningless without outcomes. The value is that your teams can deliver impact faster: software that changes how end users do their work for the better, in ways that move the mission forward.
That only happens when teams do the work up front to consider the behavior changes they are trying to drive, define what success looks like from the start, and shape the work around outcomes instead of outputs. User stories are the practice that forces that thinking.
When your teams write user stories consistently, three things happen:
- Outcomes get clarified before the work begins. Teams articulate the behavior change they expect before they start building. They are not just shipping a feature; they are stating a hypothesis about how that feature will change what users do. That gives them something concrete to go measure after they ship, and a way to know whether the work actually moved the mission forward.
- The probabilistic surface area shrinks. Remember that AI is probabilistic: it draws from a vast space of possible responses. The more specific your inputs, the smaller that space becomes. A user story with acceptance criteria scopes AI into a tightly defined area: build this feature, for this user, and here is exactly how the software should behave. You are containing the blast radius of what AI can guess at.
- Non-determinism comes under control. AI produces different output every time, but specificity constrains the range of variation. When you define exact scenarios with pass/fail criteria, AI has far less room to vary in ways that matter. Different runs may still produce different code, but the behavior converges because you told it precisely what "done" looks like.
This is the first guardrail you are learning today: specificity as a control mechanism. A structural change in how your teams define the work, scope the boundaries, and take control over what AI delivers.
Right-Sizing: Not Everything Is a User Story¶
User stories are your default tool for defining work, but not every task needs one. Match the approach to the complexity:
- Small ask: just say it in plain English. "Change the header color to blue." No template needed.
- Right-sized ask: write a user story with acceptance criteria. This is your default for any feature with multiple parts or expected behaviors.
- Too-big ask: if your acceptance criteria keep growing and you cannot list them all, the story is too big. Break it into smaller, independently deliverable pieces first, then write a story for each one. This is called decomposition, and your AI assistant can help you do it.
A good rule of thumb: if a story has more than 4-5 acceptance criteria, it is probably trying to do too much. Each piece should be small enough that you can clearly define what "done" looks like. If you cannot define "done," that is your signal to break it down further.
In Your AI Assistant
When you get to the challenge after this lesson, practice using user stories as a means of prompting. Send both the story and the acceptance criteria to your AI assistant, and it will start building.
This is vibe coding in action. You describe what you want, AI builds it, and then you go back and forth. Review what it built. Check the acceptance criteria. Tell it what to fix. Ask it to handle an edge case you forgot. Your AI assistant is a collaborator in this process, not a vending machine you put a prompt into and hope for the best.
For small tasks, skip the template entirely. Just say what you need in plain English:
Change the header background color to dark blue.
If a feature feels too big, ask your AI assistant to help you break it down:
This feature feels too big for one story. Help me break it into
smaller, independently deliverable pieces. Each piece should be
small enough for one user story with 2-4 acceptance criteria.
You do not have to figure out the right size on your own. Use your AI assistant to decompose, draft acceptance criteria, or think through edge cases. The back and forth is the workflow.
When you get to the challenge after this lesson, practice using user stories as a means of prompting. Send both the story and the acceptance criteria to your AI assistant, and it will start building.
This is vibe coding in action. You describe what you want, AI builds it, and then you go back and forth. Review what it built. Check the acceptance criteria. Tell it what to fix. Ask it to handle an edge case you forgot. Your AI assistant is a collaborator in this process, not a vending machine you put a prompt into and hope for the best.
For small tasks, skip the template entirely. Just say what you need in plain English:
Change the header background color to dark blue.
If a feature feels too big, ask your AI assistant to help you break it down:
This feature feels too big for one story. Help me break it into
smaller, independently deliverable pieces. Each piece should be
small enough for one user story with 2-4 acceptance criteria.
You do not have to figure out the right size on your own. Use your AI assistant to decompose, draft acceptance criteria, or think through edge cases. The back and forth is the workflow.
When you get to the challenge after this lesson, practice using user stories as a means of prompting. Send both the story and the acceptance criteria to your AI assistant, and it will start building.
This is vibe coding in action. You describe what you want, AI builds it, and then you go back and forth. Review what it built. Check the acceptance criteria. Tell it what to fix. Ask it to handle an edge case you forgot. Your AI assistant is a collaborator in this process, not a vending machine you put a prompt into and hope for the best.
For small tasks, skip the template entirely. Just say what you need in plain English:
Change the header background color to dark blue.
If a feature feels too big, ask your AI assistant to help you break it down:
This feature feels too big for one story. Help me break it into
smaller, independently deliverable pieces. Each piece should be
small enough for one user story with 2-4 acceptance criteria.
You do not have to figure out the right size on your own. Use your AI assistant to decompose, draft acceptance criteria, or think through edge cases. The back and forth is the workflow.
When you get to the challenge after this lesson, practice using user stories as a means of prompting. Send both the story and the acceptance criteria to your AI assistant, and it will start building.
This is vibe coding in action. You describe what you want, AI builds it, and then you go back and forth. Review what it built. Check the acceptance criteria. Tell it what to fix. Ask it to handle an edge case you forgot. Your AI assistant is a collaborator in this process, not a vending machine you put a prompt into and hope for the best.
For small tasks, skip the template entirely. Just say what you need in plain English:
Change the header background color to dark blue.
If a feature feels too big, ask your AI assistant to help you break it down:
This feature feels too big for one story. Help me break it into
smaller, independently deliverable pieces. Each piece should be
small enough for one user story with 2-4 acceptance criteria.
You do not have to figure out the right size on your own. Use your AI assistant to decompose, draft acceptance criteria, or think through edge cases. The back and forth is the workflow.
Discussion: The Dangers of One-Shotting
Team Discussion | ~3 minutes total | Discuss at your table.
Some people try to give AI one big, vague prompt, or hand it one large task, and expect a finished product in a single shot. This is called one-shotting. AI will do it. It will use its probabilistic nature to fill in every blank you left open: making design decisions, choosing behaviors, resolving ambiguity. It will produce something that looks complete.
Discuss with your team: when is letting AI fill in the blanks useful, and when does it introduce risk? What changes when you use user stories to control those decisions instead?
Key Insight
User stories are not a prompting trick. They are a practice for connecting what you build to why it matters. Specificity is your first guardrail: it shrinks the probabilistic surface area, constrains non-determinism, and gives you a pass/fail checklist for what AI delivers. Scale down for simple tasks. Scale up by decomposing when the work is too big for one story.