Story Generation
After the planning stages are complete (or after a light scoping conversation), the SDM works with Conductor to generate user stories — business-level features described from the user's perspective.
How It Works
Conductor proposes stories
Conductor uses the approved requirements, technical analysis, and architecture as context. It generates a set of stories, each with a title, user story description, acceptance criteria, and complexity score. No starting from scratch — everything is grounded in what was already decided.
SDM reviews in the review table
Stories are presented in a review table. The SDM can:
- Approve a story as-is
- Edit the title, description, or acceptance criteria
- Split a story that is too large
- Merge stories that overlap
- Reject a story that does not belong
Nothing enters the backlog without the SDM's explicit approval.
Stories enter the backlog
Approved stories are created in the project backlog. Each story is linked to its source phase and carries forward the full context thread — requirements, architecture, and the planning decisions that produced it.
Story Fields
| Field | Description |
|---|---|
| Title | Short, descriptive name for the feature |
| Description | User story format — who, what, why |
| Acceptance criteria | Testable conditions that define "done" |
| Complexity | Score used for estimation and sprint planning |
| Phase | The phase this story was generated from |
Enrichment
Stories are created in two steps internally:
- Generate — Conductor outputs lightweight stories during the conversation (title, type, description, dependencies). Created with
enriched: false. - Enrich — Each story is enriched individually, which generates detailed acceptance criteria, architectural notes, files to create or modify, implementation steps, and a context pack. Marked
enriched: true.
What Happens Next
Once stories are in the backlog, the SDM can:
- Assign them for decomposition into technical tasks
- Add them to a sprint
- Push them to Azure DevOps for visibility