Idea Flow
Models
Idea Flow
  • Welcome!
    • Why Models?
    • Why Principles?
  • Agility & Transformations
    • Intro to Agile
      • What Does Agile Mean?
      • What Is An Agile Mindset?
    • Intro to Transformation
      • Why Transform?
      • How Is The Transformation Done?
      • Who Transforms?
      • Which Areas or Functions Transform?
      • How Long Does A Transformation Take?
  • Agile Transformation (Idea Model)
    • Intro to IDEA
      • Leadership-Strip (Tanzaku)
      • Managing The Change
      • Metrics
      • Coaching Plan
        • Coaching Assessment
    • Initial Exposure
      • Training & Coaching
      • Assessment
    • Develop Basics
      • Training & Coaching
      • Assessment
    • Evolve & Reflect
      • Training & Coaching
      • Assessment
    • Accelerate & Kaizen
      • Training & Coaching
      • Assessment
  • Delivery Approach (Flow Model)
    • Intro to Flow
      • Flow of Work
      • Dev Sec Ops
    • Conceptualise
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Commence
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Construct
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Confirm
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Complete
      • Process
      • Outputs
    • Check
      • Process
  • Scrum, Kanban & Other Agile Frameworks
    • Double-Loop Scrum
    • Kanban
  • 3D Work-Breakdown
    • Intro to Work Breakdown
    • Direction
    • Discovery
    • Delivery
    • Flow & 3D Work-Breakdown
  • Roles & Responsibilities
    • Overview
      • Trust Circles
      • Enterprise View
    • Core Team Roles
      • Scrum Master / Iteration Manager
      • Product Owner
      • Developer
      • Tester
      • Business Analyst
      • Infrastructure
    • Extended Team Roles
      • Product Manager
      • Test Lead
      • Tech Lead
      • Subject Matter Expert (SME)
      • UX/UI Designer
      • Infrastructure Lead
      • Project Manager
      • Solution Architect
      • Delivery Manager
      • Change Analyst
    • Trusted Advisor Roles
      • Project Sponsor
      • Stakeholders
  • Topics
    • Prioritisation
    • Estimation
      • Estimation Overview
      • Epic Estimation
      • Initiative Estimation
    • Planning
      • Sprint / Iteration Planning
      • Release Planning
      • Quarterly Planning
      • Problem Statement
    • Ceremonies
      • Showcase
      • Scrum of Scrums
      • Stand-up
      • Retrospective
      • Elicitation
      • Elaboration
      • Acceptance Criteria (AC)
    • Artefacts
      • Tech Spike
      • Definition of Done
      • Social Contract
      • Personas
      • Lean Canvas
      • User Stories
    • Toolkit
      • Success Sliders
      • ICaRuS Scoring
      • Accountability Cards
    • Quality
      • Test Strategy
      • Test Plan
      • Quality Attribute Definitions
      • Test Type Definitions
      • Regression Test Suite Definitions
      • Defect Definitions
      • Defect Severity
      • Defect Priority
      • Agile Testing Quadrants
      • Risk-Based Testing
    • Templates
      • 3rd Party Handover Template
      • Audit Logs
    • Data
      • Information Management
    • Kanban
  • Agile Testing (4Aces Model)
    • Intro to Agile Testing
      • Test Principles
        • Test Automation Principles
      • Test Artefacts
      • Test Triangle
      • Agile Testing Quadrant
    • Arrange
    • Act
    • Assert
    • Annihilate
  • INCIDENT MANAGEMENT (TRACeR MODEL)
    • Intro to TRACeR
      • What is Incident Management
      • Incident Management Workflow
    • Triage
    • Review
    • Action
    • Check
    • Resolve
  • Change Management (3C Change Model)
    • Intro to 3C Change
      • What is Change?
      • What is Change Management?
      • 7Rs of Change Management
      • Model States
      • Implementation
    • Capture
      • Priority
      • Experience
      • Impact
      • Change Types
    • Consider
      • Risk
    • Conduct
      • Plan
        • Change Activities Matrix
      • Perform
        • Rollback or Roll-forward
      • Prove
        • Change Result/Status
  • Faciliation
    • Intro to Faciliation
      • Agile Facilitation
      • Planning and Running a Workshop
    • Meetings
      • Meeting Prep
    • Workshops
      • Quarterly Planning Workshop
      • Integrated Culture Workshop
    • Games
      • Dice Game
      • Battleships
      • Kanban Pizza Game
    • Icebreakers
      • Check Your Personal Thinking Style
  • Agile Coaching (A6 Model)
    • Intro to Coaching
    • Agree
    • Address
    • Assess
    • Align
    • Assign
    • Account
  • Agile Leadership
    • Intro to Agile Leadership
  • Strategy
    • What is Strategy?
    • What is Vision?
    • What is a Mission?
    • What are Values and Drivers?
    • Intent-based Outcomes
    • MunroMaps
  • OKRA
    • OKRS + ACTIONS = OKRA
      • Implementation
      • Cycle Cadence
    • Objectives
      • OKRs
    • Key Results
    • Actions
  • Agile Software Architecture (C4 Model)
    • Intro to Architecture
      • Role of the Architect
      • SOLID Principles
      • DRY Principle
      • Single Source of Truth (SSOT)
    • Context
      • Examples
    • Container
      • Examples
    • Component
      • Examples
    • Code
      • Examples
    • Patterns
      • Back-end for Front-end (BFF)
      • Event-Driven Microservices
  • Portfolio Management (PMO Practice Model)
    • Intro to Portfolio Management
      • Practices & Flow
      • Objectives
      • Types
      • Maturity Assessment
      • Setting Up
        • Charter
    • Demand Practice
    • Risk Practice
    • Performance Practice
      • Cost of Delay (CoD)
      • Metrics
    • Report Practice
    • Delivery Practice
    • Asset Practice
    • Change Practice
  • RAFT
    • RAFT Framework
  • Tools
    • Jira
      • Best Practice
      • Printing Physical Cards
    • Confluence
      • Best Practice
      • Example Confluence Layout
    • Power BI
      • Power Query M
    • Miro
      • Best Practice
  • FAQs
    • Frequently Asked Questions
    • Glossary of Terms
  • Thanks & Contributors
    • Thanks
    • License
Powered by GitBook
On this page

Was this helpful?

  1. Topics
  2. Ceremonies

Acceptance Criteria (AC)

We use this to .... so that we can ....

These basically form the boundary or scope of your Story, if you will. Technically, anything that falls outside of the acceptance criteria is not to be built as part of the story.

ACs sometimes could have:

- Lo-Fi prototype (e.g. sketches, wireframes, etc.), Narrative, Context Diagram, Dependent Stories, Constraints.

And less often have:

- Technical Design, Data model, Consider points, Link to high-level scenarios, GUI design.

The ABCs of Acceptance Criteria

Abstract

A test is readable as a document describing system behaviour. Amplify your test's essential elements, and bury its irrelevant details and clutter. Anyone, including non-techies, should be able to follow the steps taken in the test and understand why it passes.

Bona fide

To ensure continual customer trust, a test must always truly exercise a system as close to production as possible. Passing acceptance tests tells the customer that what they asked for is complete and working.

Cohesive

A test expresses one goal accomplished by interacting with the system. Don't prematurely optimize by combining multiple scenarios into a single test.

Decoupled

Each test stands on its own, not depending upon or being impacted by results of other tests. A failure caused by problems in another test can be difficult to decipher.

Expressive

A test is comprehensible as documentation, not requiring research to understand. Name it according to the goal it achieves. As with unit tests, refactor each test to improve the ability of a third party to understand its intent. You should always eliminate magic numbers, replacing them with constants as appropriate.

Free of duplication

Eliminate duplication across tests (and even within the same test) before it eliminates you! Duplication increases risk and cost, particularly when changes to frequently-copied behaviour ripple through dozens or more tests. Duplication also reduces the use of abstraction, making tests more dense and difficult to follow.

Green

Once a story is complete, its associated ATs must always pass. A failing AT should trigger a stop-the-line mentality. Don't allow your test suite to fall into disarray by allowing failures to be ignored

Types of Acceptance Criteria:

Gherkin Reference (Given When Then)

  • Used when Behaviour/Scenario driven

Format

Scenario: <Name for the behaviour that will be described>

Given <Beginning state of the scenario>

When <Specific action the user makes>

Then <Outcome of the action in "When">

And <Used to continue any of the three previous statements>

E.g.

User Story
Acceptance Criteria

As a Motor claims consultant

I want a TTD relating to fraud automatically generated against the claim lodged if claim could be fraudulent

So that I know that the claim needs to undergo further investigation in relation to fraud

AC01: When Motor claim is lodged via DISC and qualifies for fraud

GIVEN a Motor claim is being lodged in DISC

WHEN the 'Auto Fraud Score’ switch is On

AND fraud score is >= 100

AND claim is submitted

THEN the Auto Fraud Score TTD will be generated

AC02: When Motor claim is lodged via DISC and does not qualifies for fraud

GIVEN a Motor claim is being lodged in DISC

WHEN the 'Auto Fraud Score’ switch is On

AND fraud score is <100

AND claim is submitted

THEN the Auto Fraud Score TTD will be NOT generated

Rule Orientated

  • Used when we don't need details of test scenarios

Format

Simple bullet list

Custom

  • Used when the above formats don't cut it, we make up what makes sense and would be clear and useful for developers and testers

Format

E.g. Truth tables, wireframes, flow charts, etc.

Last updated 2 years ago

Was this helpful?