Definition of Ready
Record what ready means, then let Frankee apply it
Most teams already have a Definition of Ready. It usually lives in a wiki page nobody opens, and the same gaps get raised in refinement every sprint. Recording it in Frankee means those standards are applied while stories are being written, instead of being caught afterwards.
What it does
Your active Definition of Ready is sent to Frankee every time it generates stories for that team. Criteria are reflected in acceptance criteria, assumptions, dependencies, and notes as they apply, so a story arrives closer to ready than it would otherwise.
It is set per team, at Team Playbook › Definition of Ready. Each team has one active Definition of Ready at a time. Saving a new one replaces the previous one rather than adding to it.
A DoR is not a gate here. Frankee does not block or reject stories that fall short. It uses your criteria as instructions while writing, and the judgement about whether a story is genuinely ready stays with your team.
Building one from the starter template
You do not start from a blank page. Frankee ships a starter template of 16 criteria across four categories, drawn from what most teams converge on. Building your DoR means choosing which of them apply to you.
-
Review the template
Every criterion has a title and a short line describing what Frankee does with it. Seven are pre-selected as a sensible starting point; the rest are yours to turn on.
-
Select what applies to your team
Take the ones you would genuinely hold a story to. A shorter DoR your team actually means is worth more than a long one nobody enforces. At least one criterion is required.
-
Set how each one should be used
Each criterion carries a usage type, which you can change per criterion. The three types are explained below.
-
Review and activate
Activating makes it live immediately. The next generation for that team uses it.
The template is the full menu: criteria cannot currently be reworded, and custom criteria of your own cannot be added yet.
The three usage types
Usage type is how you tell Frankee what kind of standard a criterion is. It is the part of the DoR most worth thinking about.
- Always include. A standard every story must meet, no exceptions. Acceptance criteria and INVEST live here for most teams.
- When relevant. A standard that applies to some stories and not others. A rollback strategy matters for a migration and is noise on a copy change. Frankee is given these criteria along with the always-include ones and asked to apply each where it genuinely fits, rather than forcing all of them onto every story.
- Human confirmation. A standard no AI can attest to, so Frankee does not try. These are never sent to the model. Instead, after generation you get a short checklist on the Generate page reminding you what your team still needs to confirm between people. Whether the whole team actually understands a story is the obvious example: Frankee has no way to know, and a confident claim that it is satisfied would be a false statement about your team.
The human-confirmation checklist is a reminder, not a record. It appears with your generated stories, you can dismiss it, and nothing about it is saved. It is not stored on the story, does not travel to Jira or Azure DevOps, and is not an audit trail.
The 16 starter criteria
Defaults below are the usage type each criterion arrives with. Items marked with a dot are pre-selected when you first open the page.
Requirements (6)
- • Acceptance criteria considered complete (always include)
- • Meets INVEST criteria (always include)
- • Priority established (always include)
- Test data needs documented (when relevant)
- Performance criteria specified (when relevant)
- Feature flags determined (when relevant)
Risks and Dependencies (5)
- • Dependencies identified with mitigation plans (always include)
- • Failure scenarios considered (always include)
- Rollback strategy defined (when relevant)
- Operational implications addressed (when relevant)
- Versioning and backward compatibility (when relevant)
Other Considerations (4)
- • Security considered (always include)
- Required documentation scoped (when relevant)
- Legal and compliance requirements detailed (when relevant)
- Third-party approvals identified (when relevant)
Human Confirmation (1)
- • Story understood by everyone on the team (human confirmation)
Changing or removing your DoR
- To change it, adjust your selection and activate again. The new version replaces the old one for that team.
- To stop using it, deactivate it. Generation continues normally, just without your criteria.
- Stories already generated do not change. A DoR shapes stories at the moment they are written; Frankee does not revisit past work.
If your DoR cannot be read, generation still runs. Frankee falls back to generating without it rather than failing the request. You get stories either way, so a problem here never blocks your team.
Getting the most out of it
- Be honest about always include. Marking everything as always include produces stories padded with sections that do not apply. The when-relevant type exists precisely so you do not have to.
- Start with the pre-selected seven. Run a sprint, see what refinement still catches, then add the criteria that would have caught it.
- Put anything social in human confirmation. Shared understanding, team agreement, and stakeholder sign-off are things people do, and labelling them this way keeps Frankee from implying they are handled.
- Revisit it after a few sprints. A DoR nobody has looked at in six months is the wiki page again.
Related: Product Context is the other input that shapes generated stories. Questions can go to Settings › Contact Support or the contact form.