methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Method session20-40 min per storyWorkshopAcceptance Criteria

Session: Acceptance Criteria Workshop

The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Method session with 3-6. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward Acceptance Criteria. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 1: Fix the story summary

    3-5 min

    Put the story as title and user-value sentence on the wall. Clarify scope questions. PO confirms understanding. Hint: If scope is still unclear after 5 min, send the story back to Discovery. Acceptance criteria without scope agreement are useless.

    FacilitatorAcceptance Criteria
  2. 2

    Phase 2: Happy-path criteria

    5-10 min

    Create Given-When-Then for the standard case. Concrete input values and observable output. At least 2-3 criteria per story. Hint: Reject vague criteria such as 'works' or 'intuitive'. For each criterion, a test question must be possible: 'How would I verify this?'

    FacilitatorStory-Update
  3. 3

    Phase 3: Edge cases and special cases

    5-15 min

    Tester drives edge-case search: null values, max values, empty input, parallel actions. Separate criterion for each edge case. Hint: If no edge cases emerge, the story is understood too superficially. At least 30% of the criteria should cover edge cases.

    FacilitatorAcceptance Criteria
  4. 4

    Phase 4: Negative paths and error cases

    5-10 min

    What happens with invalid input, missing permission, or external failure? State the expected error message or system response as a criterion. Hint: Negative paths are often forgotten. The PO decides whether the error case belongs in the story or as a separate story. Both are valid, but must be deliberate.

    FacilitatorStory-Update
  5. 5

    Phase 5: Review and transfer

    3-5 min

    Read the criteria aloud. Engineer and tester confirm implementability and testability. Transfer the criteria into the story tool. Hint: Reading aloud exposes ambiguities. If roles disagree, clarify immediately instead of carrying it into the sprint.

    OwnerAcceptance Criteria
  6. 6

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerAcceptance Criteria
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Acceptance Criteria Workshop

Goal

Artifact: Acceptance Criteria

Working Question

Which concrete, testable criteria describe the happy path, edge cases, and negative paths of this story so clearly that all three roles share the same Definition of Done?

Context

Story descriptions with user value; known constraints (performance, compliance, browser support); Definition of Done; similar existing stories as reference.

Setup

  • Format: Method session
  • Duration: 20-40 min per story
  • Mode: Workshop
  • Participants: One facilitator (PO, Scrum Master, or BA); Product Owner for scope; at least one engineer; one tester for edge cases; optionally a domain expert for deeper subject matter.
  • Owner: One facilitator (PO, Scrum Master, or BA)
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Acceptance Criteria. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Whiteboard or Miro board with columns per story; story cards or tickets visible; Given-When-Then template as a banner; pens; timer; Definition of Done as a reference.

Preparation

One section per story on the board. Given-When-Then template visible. Definition of Done in the sidebar. Rule: no vague criteria (fast, simple, beautiful). Concrete, testable statements only.

Agenda

  1. Phase 1: Fix the story summary (3-5 min) Owner: Facilitator Action: Put the story as title and user-value sentence on the wall. Clarify scope questions. PO confirms understanding. Hint: If scope is still unclear after 5 min, send the story back to Discovery. Acceptance criteria without scope agreement are useless. Output: Acceptance Criteria

  2. Phase 2: Happy-path criteria (5-10 min) Owner: Facilitator Action: Create Given-When-Then for the standard case. Concrete input values and observable output. At least 2-3 criteria per story. Hint: Reject vague criteria such as 'works' or 'intuitive'. For each criterion, a test question must be possible: 'How would I verify this?' Output: Story-Update

  3. Phase 3: Edge cases and special cases (5-15 min) Owner: Facilitator Action: Tester drives edge-case search: null values, max values, empty input, parallel actions. Separate criterion for each edge case. Hint: If no edge cases emerge, the story is understood too superficially. At least 30% of the criteria should cover edge cases. Output: Acceptance Criteria

  4. Phase 4: Negative paths and error cases (5-10 min) Owner: Facilitator Action: What happens with invalid input, missing permission, or external failure? State the expected error message or system response as a criterion. Hint: Negative paths are often forgotten. The PO decides whether the error case belongs in the story or as a separate story. Both are valid, but must be deliberate. Output: Story-Update

  5. Phase 5: Review and transfer (3-5 min) Owner: Owner Action: Read the criteria aloud. Engineer and tester confirm implementability and testability. Transfer the criteria into the story tool. Hint: Reading aloud exposes ambiguities. If roles disagree, clarify immediately instead of carrying it into the sprint. Output: Acceptance Criteria

  6. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Acceptance Criteria

Closeout

  • Update result artifact: Acceptance Criteria
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

Acceptance Criteria: Acceptance Criteria Workshop

Working Question

Which concrete, testable criteria describe the happy path, edge cases, and negative paths of this story so clearly that all three roles share the same Definition of Done?

Context

Story descriptions with user value; known constraints (performance, compliance, browser support); Definition of Done; similar existing stories as reference.

Participants

  • Owner: One facilitator (PO, Scrum Master, or BA)
  • Participants: One facilitator (PO, Scrum Master, or BA); Product Owner for scope; at least one engineer; one tester for edge cases; optionally a domain expert for deeper subject matter.

Input

Whiteboard or Miro board with columns per story; story cards or tickets visible; Given-When-Then template as a banner; pens; timer; Definition of Done as a reference.

Template

Acceptance Criteria Workshop Checklist

  • Goal and context clarified
  • Input material gathered
  • Participants and roles named
  • Execution prepared according to the runsheet
  • Output artifacts created
  • Acceptance Criteria updated
  • Story updated
  • Open questions documented
  • Next step set with owner and date

Completion Check

  • Acceptance Criteria is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

Acceptance Criteria Workshop Working Template

View templateCompact working template for Acceptance Criteria Workshop with context, input, output artifacts, and next step.
checklist

acceptance-criteria-workshop-working-template.md

Compact working template for Acceptance Criteria Workshop with context, input, output artifacts, and next step.

Acceptance Criteria Workshop Checklist

  • Goal and context clarified
  • Input material gathered
  • Participants and roles named
  • Execution prepared according to the runsheet
  • Output artifacts created
  • Acceptance Criteria updated
  • Story updated
  • Open questions documented
  • Next step set with owner and date
Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Acceptance Criteria.
  • Criteria versioned as part of the story. If changed after sprint start, note the reason in the story comment. Keep criteria templates per domain in the wiki and review every 3-6 months.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet