{{ result.summaryTitle }}
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
Use the ticket title or feature name reviewers will recognize.
Keep it role-based, for example account admin, API client, or warehouse operator.
This becomes the acceptance context, not a hidden implementation detail.
Each line becomes one positive acceptance criterion.
Rows stay local and recompute instantly.
Each line becomes a negative or boundary acceptance criterion.
Gherkin works best for QA automation handoff; checklist works best for backlog grooming.
Use a short ticket or project prefix, for example AC, PAY, or API.
Use this when adding criteria to an existing ticket.
first ID
Leave as product review unless the ticket is specifically API, UI, or workflow focused.
Off keeps the draft focused on the supplied behaviors and edge cases.
{{ include_quality_criteria ? 'On' : 'Off' }} 
{{ result.draftText }}
ID Type Given When Then Copy
{{ row.id }} {{ row.typeLabel }} {{ row.given }} {{ row.when }} {{ row.thenText }}
Add at least one expected behavior to generate criteria.
Review point Status Evidence Next action Copy
{{ row.point }} {{ row.status }} {{ row.evidence }} {{ row.action }} 

        

      

    

  

                

                

                    

                        

                            Tags: Devtools, Productivity
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  
  
Acceptance criteria describe the conditions a feature or story must satisfy before the work can be accepted. Good criteria are specific enough for a reviewer to judge, small enough to test, and written around user-visible behavior rather than private design choices.

  
They sit between a backlog title and a test plan. The title says what the team intends to build, while the criteria define the observable evidence that the work is done for a named actor and outcome. A story with clear criteria is easier to discuss in refinement, easier to test in QA, and less likely to surprise the product owner at review time.

  

    Given, When, and Then blocks showing a known state, observable action, and expected result for one acceptance row
  

  
Given-When-Then wording is one common way to make acceptance criteria concrete. The Given part describes the starting condition, the When part names the action or event, and the Then part states the result that can be checked. The format does not make weak criteria strong by itself. Vague words such as fast, secure, or simple still need measurable states, messages, limits, or examples.

  
Acceptance criteria are not the same as a team-wide Definition of Done. The Definition of Done covers the shared quality bar for all work. Acceptance criteria belong to a specific backlog item and say what must be true for that item to satisfy the user or business need.






  
Technical Details:

  
A useful acceptance criterion has three parts that can be checked without reading the developer's mind: a known state, a trigger, and an expected outcome. The state should be a real precondition, the trigger should be one action or event, and the outcome should describe visible behavior, a response contract, a handoff state, or another piece of evidence that a reviewer can inspect.

  
Gherkin scenarios use this shape because it keeps examples close to the language of users and domain experts. In that style, a scenario is both specification and test candidate. The same row can be read by a product owner during refinement, a developer during implementation, and a tester during acceptance review.

  
Rule Core:

  

    

      
      
        

          Source cue
          Generated row
          Review meaning
        

      
      
        

          Expected behaviors
          Each unique non-blank line becomes a Positive criterion with an ID, title, Given, When, Then, and source cue.
          The row should confirm one expected action or result that helps the named actor reach the stated outcome.
        

        

          Edge cases and rules
          Each unique non-blank line becomes a Negative criterion that starts from the boundary condition and blocks unintended state change.
          The row should cover validation, permissions, unavailable states, limits, or failure handling.
        

        

          Add quality criteria
          When enabled, two Quality rows are added for accessible feedback and operational evidence.
          These rows make QA handoff deeper when status, focus, audit, notification, or history behavior matters.
        

        

          Test layer
          The Given and Then wording shifts for product review, UI behavior, API contract, or workflow handoff.
          The scenario keeps the same source behavior but uses review language that fits the acceptance surface.
        

        

          Criteria ID prefix and Starting number
          The prefix is normalized to uppercase letters, numbers, underscores, and hyphens. The first number is rounded into the 1 to 999 range and displayed with at least two digits.
          ID rows can continue an existing ticket sequence while keeping the ledger easy to reference.
        

      
    

  

  
The draft text has three output formats. Gherkin scenarios creates a feature block with one scenario per row. Criteria checklist creates Markdown checkboxes that combine the ID, type, title, Given, When, and Then text. QA handoff contract expands each row with type and source cue so testers can trace why a criterion exists.

  

    

      
      
        

          Signal
          Condition
          Correction
        

      
      
        

          Needs input
          Feature or story, Actor, or at least one behavior line is missing.
          Fill the missing field before trusting the draft or ledger.
        

        

          Behavior coverage
          Positive row count follows the unique behavior lines supplied.
          Split bundled behaviors so each row stays independently testable.
        

        

          Negative coverage
          No edge case or rule line is present.
          Add blocked states, limits, validation failures, or permission cases before sprint commitment.
        

        

          Specific language
          Common vague terms such as fast, secure, simple, or user-friendly appear in behavior or edge-case cues.
          Replace vague language with thresholds, messages, states, or observable outcomes.
        

        

          Ready for grooming
          Required inputs are present and the review checklist has no Fail or Review status.
          Still read the criteria with the team; the status is a drafting signal, not acceptance approval.
        

      
    

  

  
The generated rows are deterministic from the current fields. They do not infer missing business rules, inspect tickets, judge whether the story is valuable, or prove that a scenario can be automated. Human review still has to confirm that each criterion represents a real agreement about the feature.






  
Everyday Use & Decision Guide:

  
Start with a ticket title in Feature or story, a role in Actor, and the value protected by the work in User outcome. Keep the actor role-based, such as account admin, API client, warehouse operator, or support agent, so the criteria read as behavior rather than department notes.

  
Put one observable behavior per line in Expected behaviors. Use Edge cases and rules for blocked states, limits, permissions, validation failures, retention windows, duplicate prevention, and other cases where the system should refuse, redirect, or explain the result. The Normalize action cleans spacing, removes duplicate rows, sentence-cases cues, normalizes the prefix, and bounds the starting number.

  
    
    
  • Choose Gherkin scenarios when testers or automation engineers expect Given, When, and Then text.
    • 
    
  • Choose Criteria checklist when the draft is going into backlog grooming or sprint planning notes.
    • 
    
  • Choose QA handoff contract when each row needs a type, source cue, and review lens for tester follow-up.
    • 
    
  • Use Criteria ID prefix and Starting number when adding rows to an existing ticket.
    • 
    
  • Turn on Add quality criteria when accessibility feedback or audit/history evidence is part of the acceptance risk.
    • 
  

  
Read Review Checklist before copying the draft. A Review status on negative coverage or specific language usually means the story still needs better examples, not that the generated text is broken. If the checklist warns about vague terms, replace them with concrete messages, limits, state names, or response fields.

  
A polished Criteria Draft should not be treated as team agreement by itself. Use Scenario Ledger to inspect each ID row, Given condition, When trigger, Then result, and source cue before handing the text to product, QA, or development.






  
Step-by-Step Guide:

  
Work from story context to behavior rows, then use the review signals to tighten the draft.

  
    
    
  1. Enter Feature or story. The summary and draft title use this value, so keep it recognizable to ticket reviewers.
    2. 
    
  2. Enter Actor and User outcome. The generated Given and Then text ties the actor to the expected value.
    3. 
    
  3. Add one line per behavior in Expected behaviors. If this field is empty, Criteria Draft says to add at least one behavior and the warning alert lists the missing input.
    4. 
    
  4. Add blocked states, validation rules, limits, and permission failures in Edge cases and rules. These become Negative rows in Scenario Ledger.
    5. 
    
  5. Choose Draft format. Confirm that Criteria Draft changes between Gherkin scenarios, checklist text, and QA handoff contract text.
    6. 
    
  6. Open Advanced if the IDs, review focus, or quality checks need adjustment. Check that Scenario Ledger shows the expected ID prefix, row type, and Given-When-Then wording.
    7. 
    
  7. Review Review Checklist. Fix any Fail or Review row before copying the draft, CSV, document table, or JSON payload into a ticket.
    8. 
  






  
Interpreting Results:

  
Acceptance criteria pack summarizes the current draft. Needs input means a required field is missing. Ready for grooming means required inputs are present and the checklist has no failure or review status. Review needed means the draft exists but at least one checklist row asks for human cleanup.

  
The strongest review signal is Specific language. A pass there only means the built-in vague-term check did not find its short list of weak words. It does not prove every row is measurable. Read each Then result and confirm that a reviewer could decide pass or fail from visible state, response data, status text, or a handoff record.

  
Use the count badges as coverage cues, not quality scores. A story with many positive rows and no negative rows can still miss the failure paths that matter most. Add edge cases until blocked states, permission changes, limits, and recovery behavior are represented in Scenario Ledger.






  
Worked Examples:

  
For an export retry flow, three behavior lines and three edge-case lines produce six criteria: three Positive rows and three Negative rows. With prefix AC and starting number 1, the ledger starts at AC-01. The draft reads as Gherkin when Draft format is set to Gherkin scenarios, and the checklist should show behavior, negative, actor, Given-When-Then, and language checks as ready while quality coverage remains optional.

  
An API token rotation story might use actor API client, behavior lines for requesting a new token and seeing the old token expire, and edge cases for missing authorization or expired credentials. Setting Test layer to API contract changes the Given text toward valid authorization and request data, while the Then text points toward response status and body expectations.

  
A troubleshooting pass starts with a draft that says Needs input. If Actor is blank and Expected behaviors is empty, the alert names the first missing requirement and Review Checklist marks behavior coverage, actor and outcome, and Given-When-Then shape for review or failure. Add a role and at least one behavior line, then check that Criteria Draft no longer shows the placeholder message.






  
FAQ:

  

    Why did the draft create more rows than I expected?
    
Each unique non-blank behavior and edge-case line becomes its own row, and Add quality criteria adds two more rows when enabled. Remove duplicate ideas or turn off the quality option if the pack should stay limited to supplied cues.

  

  

    Why is negative coverage marked for review?
    
Edge cases and rules is empty. Add failure states such as missing permission, invalid input, unavailable status, duplicate action, or limit exceeded before relying on the pack for sprint commitment.

  

  

    Can the generated Gherkin be used as automated tests?
    
It is a draft shape, not executable test code. The text still needs step definitions, data setup, assertions, and agreement that the Given, When, and Then wording matches the product domain.

  

  

    Why did the specific-language check warn about my row?
    
The supplied cues include a common vague term such as fast, secure, simple, or user-friendly. Replace the term with a concrete timeout, validation message, visible state, response field, or reviewable threshold.

  

  

    Does the feature text get sent to a server?
    
The criteria are built in the page from the entered fields, and the source shows copy and download helpers rather than a server submission path for feature, behavior, or edge-case text.

  






  
Glossary:

  

    
Acceptance criteria

    
Item-specific conditions that a feature or story must satisfy before it can be accepted.

    
Given-When-Then

    
A scenario pattern that states a known condition, a trigger, and the expected result.

    
Positive criterion

    
A row generated from an expected behavior that should succeed under the named context.

    
Negative criterion

    
A row generated from an edge case or rule where the system should block, redirect, or explain the result.

    
Quality criterion

    
An optional acceptance row for accessible feedback or operational evidence during QA handoff.

  






  
References: