“Three Amigos” is what Matt Wynne calls the meeting to discuss the Gherkin scenarios before development starts. The Three Amigos involves the business, development and testing voices. However who turns up, where they meet, what they produce in the meeting, the homework to complete after the meeting, and who does that homework can all vary depending on the particular team.
What the Three Amigos meeting is for
In Lean-Agile scope is refined in an iterative-incremental manner. This gives a process suggestive of a spiral or snail. Features get refined into smaller user stories which in turn get turned into scenarios to drive automated testing.
Agile Requirements Snail
The Three Amigos meeting is about the transition from user stories to scenarios. It is meant to happen before development starts, part of a good test first approach. It is meant to happen just before development starts.
The Three Amigos is more a Kanban thing than a Scrum thing. The nearest Scrum equivalent the sprint planning meeting. Both meetings are about defining what is about to be developed. But sprint planning involves the whole team, happens on a regular schedule, and doesn’t generate automated tests. The Three Amigos is a much smaller group, happens on demand, and generates tests.
Who comes to the Three Amigos
The Three Amigos is called the Three Amigos because it involves three voices: business, development and testing. That might mean the product owner, a developer and a tester turn up but other possibilities exist.
On my current team this has turned into the “Four Amigos”: BA (for product owner), developer, tester, and UX designer. Although there are four roles that doesn’t necessarily mean four people. Often more than one developer is involved – front end and back end for example – so the meeting has more than four people.
I would not recommend less than three. Leaving out the business voice means you don’t really know the requirements. Leaving out the development voice means you don’t have insight into the potential solution. Leaving out the testing voice means you won’t factor in the edge cases that neither of the other roles normally thinks about.
Where the Three Amigos happens
The Three Amigos is a meeting but that doesn’t necessarily mean a meeting room. As it happens one of my currents teams, the one with the most people, tends to do the Three Amigos in a meeting room with a projector to look at screens and Gherkin.
In contrast another couple of teams have the three amigos in an informal fashion at their desks. That is one of the advantages of collocation. With only 3 or 4 people, who sit together anyway, you can have that conversation without physically moving.
What is produced in the Three Amigos
The Three Amigos is about Gherkin scenarios. But you’ve got two choices:
- Brainstorm a list of scenario titles
- Write fully fleshed out scenarios
Although it would be nice to end up with fully fleshed out scenarios in the meeting I’ve found that the teams usually settle for brainstorming the scenario titles. Generally this means the business rules.
Homework to complete after the meeting
If the Three Amigos only agree the scenario titles, somebody has to fill in the gaps. What I call “homework”. Take each scenario title off the list and add the Given, When and Then clauses.
Who does the homework
Who writes the gherkin is a choice depending on availability and skill set. I have a preference for Business Analyst doing it but it doesn’t have to be them.
Whilst I agree that items are progressively refined (I prefer to say Story -> Features -> Scenarios, as this allows an initial story to focus on outcomes, the In order to… part rather the solutions, I Need… part); and this is best undertaken collaboratively – the three amigos – it seems that your posts suggest that this happens as a one off exercise.
I would say that the three amigos are expected to refine features and scenarios iteratively over the life of the story – in a series of collaborations, not just in a single event. In this sense, 3 amigos is a useful ‘model’ for collaboration, not a format for a meeting.
I think we use the term “Feature” for different things. I use the term “Feature” for what other people call an “Epic”, i.e. a very large User Story or theme or some such. Bigger than, and includes, fine grained User Stories. You seem to be using “Feature” as part of a User Story. For me that is a Scenario, as in Cucumber/Gherkin scenario.
I very much believe in iterative refinement of requirements. I wrote about that in the Agile Requirements Snail – Feature to User Story to Scenario. The 3 amigos is a meeting within that larger context and specifically about the transition from User Story to Scenario.
Yes, feature is a rather overloaded term. I use Feature in this way because it seems to fit better with Gherkin (which defines Features and Scenarios) and helps me make a clear distinction between Story (fuzzy, starting point) and Feature (concrete, end point). [http://blog.mattwynne.net/2010/10/22/features-user-stories/]
Most of my Stories impact a single feature, but they don’t have to; I try to model features as focusing on a particular domain, and this means some stories cut across those domains.
Yup, “feature” is overloaded. I find teams start by assuming user stories are Gherkin Features but then go on to discover Gherkin Features are actually more interesting and enduring and that user stories can cut across them.
Great post Steven, the challenge is have as a online BA is that I am required (business policy) to write use cases (post business creating user stories with a supporting process flow for Design and then write bdd style user stores for the agile dev. This involves a lot of repetition i’ translating requirements to different teams and I’m struggling to find a common solution for all parties. We have also introduced 3 amigos and I am keen to understand what the agenda or outcome should be for a meeting. Would you agree that’s 1) BA gives overview of feature and value 2) why and benefits of feature 3) ux gives overview of wireframes 4) brainstorm scenarios with dev and test? The other challenge is we don’t have a product owner who is 100 percent assigned and only has limited availability so I as the BA am also expected to play the role of a PO.
What do you mean by feature size? A feature does not contain enough info at this stage yet in order to estimate any meaningful size. So what do you suggest in this case?
I talk a little bit about Feature Size in my Agile Requirements Snail post.