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, and checked again when a sprint is being planned, instead of being caught afterwards.

What it does

Your active Definition of Ready is used in two places.

• Writing stories. It 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.
• Planning a sprint. The Planning Agent checks every item it proposes against your criteria and marks each one Ready, Not Ready, or Cannot Fully Assess, naming the criteria involved. Where a gap is a writing problem it offers to draft the missing content, which you can post to the work item as a comment.

The same criteria drive both, so a standard you add is applied to new stories and surfaces on existing work at planning time without any further setup.

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.

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.

1. 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.

2. 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.

3. 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.

4. 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. The Planning Agent honours the same distinction: a when-relevant criterion that does not bear on an item is set aside rather than counted against it, which is what stops every item in a plan reading as Not Ready.
• Human confirmation. A standard no AI can attest to, so Frankee does not try. These are never sent to the model, and the Planning Agent reports them as unassessable rather than guessing. 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 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.

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.