Who are the Three Amigos in a discovery workshop, and what does each perspective contribute?
answer
- Three perspectives, not three job titles
- Held before the work is built
- Intent, feasibility, what could go wrong
- Agreement written down as concrete examples
- The conversation is the deliverable
basics
~20 sThe Three Amigos are three perspectives that meet before a requirement is built: business, which owns what problem is being solved and why; development, which owns how it could work; and testing, which owns what could go wrong.
solid answer
~50 sThe Three Amigos are three **perspectives**, not three job titles: the business or product perspective, which owns what problem is being solved and why; the development perspective, which owns how it could work and what it would cost; and the testing perspective, which owns what could go wrong. They meet briefly before the work is built, take one small requirement, and push on it until they can state concrete examples they all agree on -- real inputs and the outcome each should produce. The value is the conversation: three views disagree early, on a board, instead of late in review or in production. Anyone holding one of those perspectives can play the part, and a fourth person -- design, operations, support -- joins when the requirement touches them. The examples the group writes become the seed of the acceptance criteria and, later, of executable scenarios.
code
pseudocode · 5 linesRULE: usage above the tier-1 cap is billed at the tier-2 rate
EXAMPLE 499 units -> 499 at tier-1 rate
EXAMPLE 500 units -> 500 at tier-1 rate # cap is inclusive
EXAMPLE 501 units -> 500 at tier-1, 1 at tier-2
EXAMPLE 0 units -> standing charge only, no usage chargego deeper
Be ready to name the three perspectives -- business, development, testing -- and say in one line what each brings, plus the fact that the session happens before the work is built rather than after.
An interviewer expects you to explain the mechanics: a small requirement, a short timebox, concrete examples written down, open questions parked, and the examples flowing on into acceptance criteria and executable scenarios.
Show that you have run these. Talk about attendance decay, requirements too big for one session, and how you keep the group on observable behaviour instead of screen design -- and give one real disagreement a session exposed.
Own the framing that this is defect prevention bought with meeting hours. Be ready to say which requirements deserve the full triad, which need only an asynchronous example review, and how you would know the practice is paying for itself.
### The problem the practice solves A requirement written by one person and read by two others is three requirements. The business author knows an intent that never reached the page; the developer fills the gaps with the cheapest implementation that satisfies the words; the tester fills the same gaps differently and raises a defect that turns out to be a disagreement about intent, not a bug. Every one of those gaps is discovered late, when the cost of closing it is a code change, a re-test and a re-plan. A **discovery workshop** attacks that directly. Before the work is built, the three perspectives sit together over one small requirement and talk until they can write down concrete examples they all recognise as correct. The examples are the receipt; the shared understanding is the product. ### The three perspectives - **Business / product** -- owns *what problem, for whom, and why now*. It answers questions of intent: is a customer with no meter reading still billed this cycle, and does the answer differ for a commercial account? - **Development** -- owns *how it could work and what it costs*. It surfaces feasibility, the data actually available, and the cheap-versus-expensive branch of a rule long before an estimate is committed. - **Testing** -- owns *what could go wrong*. It supplies the boundaries, the empty and duplicate cases, the interrupted run, and above all the **oracle**: how anyone will be able to tell the behaviour is wrong once it exists. "Amigo" is a perspective, not a chair. A single person may carry two of them on a small team; a requirement that touches operations or a regulator adds a fourth voice. What is not negotiable is that all three perspectives are *present*: a session of business plus development produces optimistic examples, and a session of testing plus development produces technically precise examples of the wrong behaviour. ### What a session actually produces Take a monthly **utility billing run**. The requirement reads "usage above the tier-1 cap is billed at the tier-2 rate." Ten minutes of conversation turns that into examples the three agree on: - 499 units of usage -- all charged at the tier-1 rate. - 500 units, exactly at the cap -- still all tier-1, because the group decided the cap is inclusive. - 501 units -- 500 at tier-1, 1 at tier-2. - 0 units -- no usage charge, standing charge only. The third and fourth of those did not exist in the written requirement. The word "above" was doing silent work, and until someone said "what happens at exactly the cap?", business and development held different answers. That single question is the whole return on the meeting. ### Why examples and not more prose A concrete example is falsifiable in a way prose is not. "Handle the tier boundary correctly" cannot be disagreed with; "500 units bills entirely at tier-1" can be, and the disagreement surfaces in the room. Examples also travel: they become acceptance criteria on the story, then the scenarios of an executable specification, then the thing a reviewer reads to check the built behaviour. Nothing is retyped from memory at each hand-off, so the intent does not drift. ### Timing, size and the common failure modes The session sits **before** the work is committed to a sprint or a build, on a requirement small enough to finish in well under half an hour. Running it after development has started converts it from discovery into a review, and its main finding -- a misunderstanding -- now costs rework. The failure modes are consistent across teams: - **Attendance decay.** The tester stops being invited, or the developer treats it as a meeting to survive. The session still happens; the challenge does not. - **Solution talk.** The group starts designing screens and schemas. A facilitator parks that and drags the conversation back to observable behaviour. - **Sign-off theatre.** The output is treated as a document to approve rather than an understanding to hold, so the examples are written by one person afterwards and nobody disagrees with them. - **Too big a requirement.** A story that takes ninety minutes to explore was never one story; the session's real finding is that it should be split. ### How to talk about it in an interview Say what each perspective owns, say the meeting is timeboxed and happens before build, and -- most importantly -- say that the deliverable is agreement expressed as concrete examples, not a document. If you can name one real disagreement a session exposed for you (a boundary, an empty case, a rule that turned out to have two rules inside it), that single anecdote carries more weight than any definition.
- If the deliverable is shared understanding, why write the examples down at all?Because understanding decays and does not travel. The written examples are the receipt of the conversation: they carry intent to whoever picks the story up next week, they become the acceptance criteria and later the executable scenarios, and they let a reviewer check the built behaviour against something falsifiable. The mistake is treating the written artefact as the goal -- examples produced without the conversation are one person's assumptions in a nicer format.
- Only the product owner and a developer are available. Do you run the session?Run it, but name what is missing and close the gap. Without the testing perspective the examples skew to the happy path: boundaries, empty inputs, duplicates and interrupted runs go unasked. A workable compromise is to run the session, then have the tester review the examples the same day and bring back the cases they would have raised. If that review keeps producing new rules, the pattern is evidence for fixing attendance rather than for dropping the practice.
- How does a discovery workshop differ from a requirements review meeting?A review inspects a finished artefact and produces comments; discovery builds the artefact together and produces examples. A review is typically driven by one author defending a document, and its questions are answered afterwards; discovery is timeboxed, deliberately unfinished, and its open questions are an output -- explicitly parked as unknowns to chase before the story is built.
It is the pre-flight briefing rather than the flight report: pilot, engineer and safety officer walk the same route before take-off, and the point is that they leave with the same route in their heads, not that a form got signed.
saying these in an interview costs you the question
- Says the Three Amigos are always exactly three named job titles
- Calls the meeting a sign-off of a written requirement
- Runs it after development has already started
- Treats the tester as a note-taker rather than the challenger
- Produces abstract acceptance criteria instead of concrete examples
- Lets the group design screens and schemas instead of behaviour