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.
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.
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.
This step is the cheapest quality win in the product. A thin brief produces stories that are plausible and slightly wrong, and answering two questions is faster than rewriting six stories.
What you get back
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.
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.
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.
Private is the default for a reason, and it is also the usual surprise. If a teammate cannot see stories you generated, visibility is almost always why.
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.
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.
Review before you push, not after. Because push is final and there is no sync back, the moment to fix a title or trim a story is while it is still in Saved Stories.
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.
Related: Product Context and Definition of Ready both shape what generation produces. Questions can go to Settings › Contact Support or the contact form.