Story Generation

From a rough idea to refinement-ready stories

Describe a feature in plain language and Frankee breaks it into user stories with acceptance criteria, edge cases, assumptions, and dependencies. You do not need to write anything resembling a user story yourself.

Before you generate

Generation works without any setup, but two things change the quality of what comes back more than anything you type into the box:

• Product Context tells Frankee what you build and who for, so stories use your vocabulary and your personas.
• A Definition of Ready applies your team's standards while the story is being written rather than after.

Neither is required. Both are worth doing before you generate anything you intend to keep.

Writing the request

Go to Backlog › Generate Stories.

Story type

You choose between two types, and the choice changes the rules Frankee writes to:

• User Story / Feature. The default. Stories are written from a real persona's perspective, and the persona is never "a developer".
• Tech Debt. Written for the team doing the work. "As a developer" becomes valid, decomposition by technical layer is appropriate, and acceptance criteria may describe API contracts, test coverage, or performance benchmarks.

You may also see stories come back labelled Enabler. That is not a type you request. Frankee adds enabler stories itself when a feature needs groundwork before it can be built.

Output format

You choose how every story in the set is written:

• Traditional. The default. Each story is a user story with acceptance criteria, edge cases, assumptions, and notes, as described below. If you never change this setting, nothing about your stories changes.
• Spec. Each story is written as a structured specification in nine sections, described under What you get back.

The format applies to the whole set, whatever story type each story turns out to be, and it cannot be changed once the set is generated. The choice is not remembered: the page starts on Traditional each time you open it.

Epic name

An epic name is required, and it does more work than it looks like. It groups the set in Saved Stories, it names the CSV file you export, and it becomes the actual epic created in Jira or Azure DevOps when you push. Give it the name you would want to see in your backlog.

Description and extras

Describe the feature or problem in plain language. There is also an additional context field for anything that does not belong in the description, and you can attach documents from your library for this one generation.

Additional context is saved with the set. Open the set in Saved Stories later and it is there, so you do not have to remember or retype it. Leave the field blank and nothing is saved.

Clarifying questions

Frankee reads your brief before it writes anything. If the brief is thin or ambiguous, it comes back with up to three targeted questions instead of guessing. If the brief is already clear, it skips straight to generating and you never see this step.

The questions are specific to what you wrote, not a generic form. You have two options:

• Answer them and your answers go into the generation alongside the original brief.
• Skip and just generate. Nothing is blocked. Frankee proceeds on the brief alone.

What you get back

In Traditional format, each generated story includes:

• A title and the story itself, in "As a, I want, so that" form.
• Acceptance criteria in Given / When / Then format, covering the happy path, edge cases, and error states.
• Edge cases, each with the scenario and the expected behaviour.
• Assumptions and dependencies. Read these first. They are where a misunderstanding shows up earliest, and they are often the most useful thing to take into a conversation with your Product Owner.
• Technical notes and a story point estimate, where Frankee can offer them.

Stories are written against the INVEST principles: independent, negotiable, valuable, estimable, small, and testable.

Spec format

In Spec format, each story has a title and up to nine sections, always in this order:

1. Objective / Target: what the story achieves and for whom.
2. Scope / Constraints: what is in scope, what is out, and the limits the work must respect.
3. Required Behavior: what the finished work must do, stated as intent.
4. Acceptance Criteria: a checklist, one checkable item per criterion.
5. Assumptions: everything the story relies on that your inputs did not confirm.
6. Test Data: the data needed to check the criteria.
7. Reference Implementation: existing work or patterns to follow.
8. Docs / Tests Expected: the documentation and tests the work should produce.
9. Security / Performance / Deploy: considerations for each, stated as intent.

An empty section is left out rather than shown blank. Dependencies, story type, priority, and a story point estimate appear as they do on a Traditional story.

Anything Frankee could not confirm from your inputs goes in Assumptions. Your brief, team details, Product Context, documents, answers, earlier stories, and Definition of Ready are the only facts it works from. A file name, a field, or how an existing system behaves that you did not tell it about is written as an assumption to check rather than as fact. Read Assumptions first, for the same reason as above.

If your Definition of Ready includes human-confirmation criteria, a short checklist appears with your results. It is a reminder of what your team still needs to confirm between people, and it is not saved.

Saved Stories

Every generation is saved automatically. You do not need to press anything to keep a set, and closing the page does not lose it. Find your sets under Backlog › Saved Stories.

A set reopens in the format it was generated in. A Spec set shows its sections, and a Traditional set looks exactly as it always has. Sets generated before the Spec format existed are Traditional.

• Spec stories cannot be edited yet. Traditional stories keep their Edit button; Spec stories show none.
• Copy Markdown appears beside Copy JSON on every Spec story, here and on the Generate page. It copies the story as Markdown: the title as a heading, each non-empty section under its own heading in order, the acceptance criteria as a - [ ] checklist, and the dependencies as a list at the end.

If you entered additional context when generating, the set shows it in its own Additional Context section, above the stories and separate from them. It is a record of what you told Frankee, not part of any story, so it is not included in the CSV export. When you push the set, it goes into the epic description (see below). Sets generated before additional context was saved do not have one.

My stories and team stories

Saved Stories has two scopes, and the difference matters:

• My stories. Everything you generated, whoever it is shared with.
• Team stories. Sets that people on your team have shared with the team.

A new set is private by default. It is visible only to you until you change it, so a colleague will not find your set in team stories just because you are on the same team. Switch a set to team visibility to share it. Only the person who created a set can change its visibility.

Exporting and pushing

Both happen from Saved Stories, not from the Generate page. Generate produces and saves the set; open it in Saved Stories to do anything with it. Select the set you want, and the actions appear with it.

Export to CSV

Downloads the set as a Jira-compatible CSV with four columns: Summary, Issue Type, Description, and Story Points. The description holds the full story, acceptance criteria, and edge cases as plain text. The file is named after the epic. For a Spec story, the export carries only the Objective and the dependencies.

The export gathers your saved stories under that epic name, so if you have generated more than one set using the same epic, they come out together in one file. Use it for trackers Frankee does not integrate with directly, or when you want a review pass in a spreadsheet before anything reaches your backlog.

Push to Jira or Azure DevOps

If your organization has a tracker connected, you can push a set straight into it. Frankee creates the epic for you from the set's epic name and files every story underneath it, so there is no manual epic step. See Integrations for connecting a tracker and pointing each team at its project.

• The set needs an epic name to be pushable. The button stays disabled without one.
• Pushing is one-way and final. Once a set has been pushed, Frankee shows the date it went and will not push it again. There is no sync: edits after that point happen in Jira or Azure DevOps.
• Nothing existing is touched. Push only creates new work items.
• A Spec story's sections become its description in Jira or Azure DevOps, each under its own heading, in the same order. Its dependencies create the same links between stories as a Traditional set's.

Additional context in the epic

The epic description carries your additional context. Frankee writes the epic description as before, then adds your additional context beneath it under an Additional Context heading, in Jira and Azure DevOps alike. It is added after the description, never in place of it, and each line becomes its own paragraph. If the set has no additional context, the epic has no such section, not an empty one.

• Very long context is shortened, and you are told first. Jira limits an epic description to 32,767 characters, including formatting, and Azure DevOps to 1 million. If yours would not fit, the set shows an amber note below the push buttons before you push. Only the additional context is shortened, never the rest of the description, and it ends with a note that the full context is in Frankee.
• A failed push loses nothing. The additional context stays saved with the set. Fix the problem and push again; you do not retype anything.
• Sets pushed before this change keep their epic as it is. Push never updates an epic that already exists, so the context is added only when Frankee creates the epic.

Getting better results

• Name the feature and the persona in your brief. Your wording also decides which parts of your uploaded documents Frankee retrieves, so specific language pulls in better background.
• Answer the clarifying questions. They exist because the brief was genuinely ambiguous.
• One feature per generation. A brief covering three unrelated things produces shallow stories for all three.
• Treat assumptions as the review surface. If an assumption is wrong, the stories built on it are wrong in a way that reads as confident.