Practices

Effective development is connected before it is anything else. These thirteen practices are how that connection is made concrete: each one is a named ritual, with named participants, that produces an artefact the next step needs.

They are listed in roughly the order a feature passes through them, though in practice several run in the same room on the same afternoon. The process is where the whole chain is followed end to end, from inception to a running cluster.

Practice	Who is in the room	What comes out
Event storming	Domain experts, developers, architects, product owner	A shared map of what happens in the domain, and where its seams are
Domain-Driven Design	Domain experts, developers, architects — then developers alone	Bounded contexts, one ubiquitous language per context, and the code that speaks it
Story mapping	Product owner, UX designer, developers, quality engineer, a user	The journey along a backbone, cut into releases that each cross it
Three amigos	Product owner, developer, quality engineer	A story whose ambiguities have been found before it is estimated
Example mapping	The three amigos, plus a domain expert when needed	Rules, examples and — the valuable part — open questions
Digital artefacts	Whoever ran the workshop, before leaving the room	A story file and a Gherkin feature file, versioned, that the tool chain reads as they stand
From examples to tickets	Product owner, developer	Story tickets carrying whole scenarios, and a machine-checkable “done”
Grooming and estimation	Product owner, the whole team	A ready, sized, ordered backlog and a forecast with a range
BDD	Everyone above	Behaviour specified in the language of the business
ATDD	Developer, quality engineer	An executable acceptance test that defines “done”
API-first	Consumer team, provider team, architect	An interface agreed before it is built
Contract-first	Both sides of any boundary	A machine-checkable agreement, and the tests that enforce it
All-in-one testing	Developer, quality engineer	One suite covering several levels without duplicating intent

Domain-Driven Design is the odd one in that list: its strategic half is a mixed-room activity like the others, but its tactical half is a discipline a developer applies alone, every day, in the naming and the structure of the code. That half is a pattern catalogue and lives with the others, under tactical DDD patterns.

What they are run with

A ritual produces something only if the people in it bring the three attitudes — test-first, user-first and contract-first. Example mapping run by people not thinking about the user produces rules nobody needed; ATDD run by people not thinking about design produces tests pinned to an implementation; API-first run by people not thinking about boundaries produces a specification for the wrong seam. Same ritual, missing disposition.

What they have in common

A defined output. A ritual with no artefact is a meeting. Each of these ends with something the next step consumes — a map, a set of examples, a contract, a failing test.

A mixed room. Every one of them puts at least two specialisms together. That is the point: the expensive defects are not coding errors, they are misunderstandings that survived a handover because nobody in the second room was in the first one.

A cheap failure mode. These practices are all attempts to move the moment of discovery earlier. An open question raised in example mapping costs an hour; the same question discovered in production costs a release.

What enforces them

Three of these — ATDD, API-first and contract-first — are only worth the words if something fails when they are breached. That tooling has its own section: testing tools.

What they are not

They are not a process to adopt wholesale. A team running two of them well is better off than a team running thirteen of them as ceremony. Start with the one that addresses the failure your team actually has — usually example mapping, because “we built the wrong thing” is the most common and the most expensive.