User stories express (business) needs through a conversation and a confirmation, stored on a card

The conversation allows to the team to understand what the (business)  domain is, naturally defining a common language: this helps provide a software design that reflects the business domain: DDD, Domain Design Driven.

The confirmation could include (lots of) examples that validate business needs. These acceptance criteria will be needed by the PO for approval and for building a customer test suite (UAT): BDD, Behaviour Driven Development.


In a nutshell, when we discuss user stories (requirements), we build a language and contexts. Instead of reinventing the wheel, we match our design of the solution and the tests to this language and contexts – simple!


This picture below aims to summarise “interaction” between User stories,  DDD and BBD.

Agile US DDD BDD 4