## Definition **Specifying collaboratively** is Gojko Adzic's term for the discipline of building shared understanding of requirements through structured interaction between business, development, and test — before any implementation begins. In [[Specification by Example - Gojko Adzic]] it is a first-class process, not a subset of the [[Three Amigos]] meeting, because the appropriate collaboration *model* varies by team context, and choosing the wrong one is a root cause of costly specifications. ## The collaboration models Adzic's research surfaces five models, ordered from highest to lowest overhead: | Model | When to use | Key benefit | |---|---|---| | Big all-team workshop | Starting out, immature product, new domain | Fastest knowledge transfer across the whole team | | Three Amigos | Domain needs frequent clarification | Easier to schedule; good multi-perspective coverage | | Pair-writing | Mature product with stable domain | Analysts write, developers review for automability | | Developer review of analyst tests | Analysts are bottleneck | Keeps developers in the loop without full meetings | | Informal conversation | Stakeholders are co-located and available | Cheapest; works when trust is high and domain is known | No model is universally correct. The choice depends on product maturity, depth of team domain knowledge, complexity of typical changes, co-location of stakeholders, and where the process bottleneck lies. ## The preparation phase Effective collaboration is not cold-start. Most teams benefit from a *preparatory phase* before the collaborative session: - A business analyst or tester works one iteration ahead to gather initial examples from stakeholders. - A developer reviews those examples early to flag automation issues. - The full workshop then refines, not creates from scratch. The risk at both extremes is real: insufficient preparation leads to sessions that stall on open questions; over-preparation produces documents so complete that participants stop challenging them — and functional gaps survive unchallenged. Adzic calls the right balance "just enough examples up front." ## Involving actual stakeholders A persistent failure pattern is routing all specification decisions through a single product owner proxy. Adzic argues that while prioritisation must be centralised, *clarification* is the team's responsibility. A product owner who does the job of "three or four people" will leave specification gaps for whatever domain they do not personally understand. Whenever possible, the people who will actually use the feature should participate in at least one specification conversation. ## Relationship to Three Amigos [[Three Amigos]] is one specific collaboration model — the three-person workshop with one developer, one tester, one analyst. Specifying collaboratively is the broader practice that encompasses all five models above, the preparation phase, and the principle that the output of any model must be concrete examples, not verbal agreement. ## Related - [[Three Amigos]] - [[Specification by Example]] - [[Key Examples]] - [[Deriving Scope from Goals]] - [[Executable Acceptance Criterion]] ## Sources - [[Specification by Example - Gojko Adzic]]