Definition
Three Amigos
The three amigos is a practice where three perspectives — business, development, and testing — review a backlog item together before it is built. The product representative explains the intent, the developer raises feasibility, and the tester probes edge cases. The collaboration surfaces ambiguity and produces shared, testable acceptance criteria early, when gaps are cheapest to fix.
Key takeaways
- The three amigos brings business, development, and testing perspectives together to review a backlog item before it is built.
- Each role probes differently — intent, feasibility, edge cases — which surfaces ambiguity while it is still cheap to fix.
- Its output is shared, testable acceptance criteria that everyone understands the same way.
- 'Three' is the three perspectives, not a fixed headcount — the point is all three viewpoints are represented.
The three amigos addresses a recurring failure: a story is written by one person, built by another, and tested by a third, each filling the gaps with different assumptions. The practice puts all three viewpoints in one short conversation before work starts. 'Three' is shorthand, not a headcount — the point is that the business, build, and test perspectives are all represented.
Each amigo pulls in a different direction, and that's the value. The business voice says what outcome is wanted and why. The development voice asks what's actually feasible and surfaces hidden complexity. The testing voice asks 'what about…' — the edge cases, error paths, and unstated rules that derail a story late. Together they convert a vague item into one everyone understands the same way.
The tangible output is shared acceptance criteria, ideally written as concrete examples or scenarios. Because all three perspectives shaped them, the criteria are both buildable and testable, and the expensive 'that's not what I meant' discoveries happen in a five-minute conversation rather than at the end of a sprint.
In Planoda the acceptance criteria a three-amigos conversation produces live on the issue itself, so the shared understanding travels with the work from refinement through review.
Related terms
- Acceptance CriteriaAcceptance criteria are the specific, testable conditions a work item must satisfy to be considered complete and correct. Written before work starts, they define the boundaries of a feature — what it must do, and how you'll know it works — turning a vague request into a checklist everyone agrees on, so 'done' is verifiable rather than a matter of opinion.
- User StoryA user story is a short, plain-language description of a feature told from the user's perspective, classically in the form 'As a [role], I want [capability], so that [benefit].' It captures who needs something and why, deliberately leaving the how to the team. Stories keep work framed around user value rather than technical tasks.
- Definition of ReadyA definition of ready is a shared checklist a backlog item must satisfy before a team accepts it into a sprint. It typically requires that the item is clear, estimated, free of blocking dependencies, and has acceptance criteria. It is the entry gate to work, the mirror image of the definition of done, which is the exit gate.
- Backlog RefinementBacklog refinement is the ongoing practice of keeping a product backlog ready to work: clarifying items, splitting large ones, adding estimates and acceptance criteria, and re-ordering by priority. Often called grooming, it is continuous rather than a single event, ensuring the top of the backlog is always well-understood and small enough to be pulled into a sprint.
- Code ReviewCode review is the practice of having one or more engineers examine a change before it merges, checking for correctness, clarity, security, and adherence to conventions. Beyond catching defects, it spreads knowledge across the team, enforces shared standards, and creates a documented rationale for why code looks the way it does — typically conducted on a pull request.