One to request, one to suggest and one to protest – the anatomy of a Three Amigos Requirements Discovery workshop
Behaviour Driven Development (or BDD) is a collaborative requirements discovery practice that uses conversations around concrete examples to build a shared understanding and deliver features that matter. The "Three Amigos" workshops are a core part of BDD practices. It is also an important requirements discovery practice used even in teams who are not officially "doing" BDD.
But how do effective agile teams run these sessions? In fact, what these teams do is less important than why they do it. Let's take a look.
The key goal of a Three Amigos workshop is to build a shared understanding. We want everyone to have a clear picture of the objectives and motivations behind a feature. And we want to avoid misunderstandings, incorrect assumptions, and overlooked details that could trip us up further down the track.
"Can you give me an example?"
These workshops aim to produce examples that illustrate acceptance criteria, and that guide development and testing activities. Concrete examples help us discover and understand the business rules around a feature. The idea is to finish up with a set of well-understood examples that cover and illustrate all of the significant scenarios of the feature. Some or all of these examples can be converted into executable specifications that give fast feedback about whether a feature actually does what it is supposed to do.
But there is a more important output of a good Three Amigos session, and it is one that is often overlooked in less experienced teams. A well-run Three Amigos workshop also gets alignment, engagement and buy-in. If you tell a development team member what to do, they may well follow your instructions as best they can. But if you explain what you need to achieve, and why, and ask them to help, you will harness their creativity. And that is where high performing teams thrive.
Three Amigos sessions happen shortly before work starts on a feature. I prefer to run them no more than a week or two before work on the feature starts. Done too early, and the team will forget important details. And new information and learning might emerge that could change the choices that the team makes during the workshop.
Scrum teams use the three amigos sessions to help with sprint planning. The deeper understanding of what needs to be done helps the team produce much more confident estimates.
Three Amigos sessions also short - for example, time-boxed to 30-45 minutes. After that, attention wanes and creativity and engagement drop. Experience shows that if you need much more time than this, then the feature is most likely too big and should be broken down into smaller slices.
The Three Amigos sessions work best when three different roles are present. That's why we call it the Three Amigos. It doesn't have to be three people, though between 3 and 6 seems to work best. But three roles do need to be present and active.
TIP: Don't artificially limit the meetings to three and only three people. Depending on the feature, you might find that other domain experts have valuable input. If you have a dedicated UX person, they may have useful input as well. And if a pair of developers or testers are likely to work together on the feature, then they both should certainly be present.
Often, we think of the Three Amigos as a PO (or BA), a developer, and a tester. During a Three Amigos session, the PO or the BA presents the problem to solve to the team. To illustrate the feature, she walks through a couple of concrete examples. She explains why a user might want this feature, and what it allows users to do that they couldn't do previously. And she lists the key business rules and constraints that she knows about.
The team members build their understanding together by asking questions about the examples ("what if...", "what else...") and business rules ("so that means..."), and this helps them come up with potential solutions. The developer will be thinking of technical constraints and possible solutions, and the tester will be thinking of edge cases and testability concerns.
Roles, not job titles
But the roles are not job titles; they are much more fluid. Another way to look at the different roles is like this:
- One to Request
- One to Suggest
- And one to Protest
Each amigos present can play any of these roles, and sometimes they play more than one.
One to Request
Note the wording here. A request is not an order: the product owner or BA is not simply presenting a set of requirements that need to be implemented. They are presenting a problem that needs solving, and inviting the team to help them solve this problem in the most effective way possible to them.
A request is also not a contract. In high-performing teams, BAs do not bring a fully finalised specifications for the team to "commit" to deliver. A common trap for teams new to BDD (and Agile) is for BAs to write user stories as highly detailed specifications. They include detailed acceptance criteria in the form of "Given-When-Then" scenarios with each story. For inexperienced teams with little knowledge of the domain, this approach may work initially. But for a high-performing team, or even a team that has been working on a project for some time, this approach is actually counter-productive. It will slow them down, reduce their creativity and limit their options.
In a well-oiled Three Amigos workshop, the main focus is not for the product owner or business analyst to tell the team what needs to be built. The main focus is for the team to show the business analyst that they understand what they need to do. And they do this through questions, discussions of concrete examples, and proposed solutions.
TIP: Three Amigos sessions are more productive if everyone is prepared. If you are the one to suggest, make sure you let the team know what you intent to discuss during the session beforehand. If you are attending a Three Amigos meeting, take the time to read the story and do a bit of homework before the session. Bonus points if all this preparation happens a day or two before the meeting. People are more creative when they have had some time to become familiar with an idea beforehand. 24 hours is ideal - the brain does remarkable things with a night of sleep.
One to Suggest
The aim of any requirements discovery workshop is to explore options and to decide on which possible solutions to our problem we would like to try. In Design Thinking, Manuel Garzarón talks about design as a two-stage process. In the first stage ("diverge"), we look for as many options or variations as we can think of. The second stage ("converge") is where we narrow down these options by applying the constraints we know about.
The One Who Suggests comes up with ideas about how to solve the problem. They ask "what if we did this?", and sketch wireframes and screen flow diagrams. This is often a developer, but not always. Software developers are good at find solutions to problems. But, as a developer, I know that we sometimes like to dive into "solution" mode, before we understand the problem fully. The one who request and the one who protest play an important role to keep the conversation from getting stuck in solution mode. They help make sure we have covered all the scenarios we need to before we start choosing solutions.
One to protest
Effective teams thrive in diverse thinking and creative tension. People who think and behave very similarly might be fine for construction work or a production line, but not for the fluid, creative, knowledge-based, learning-intensive activities typical of software projects.
Three Amigos workshops need dynamic tension. They need someone to challenge assumptions, to question incertitudes, and to highlight ambiguities. A Three Amigos workshop needs a cross-examiner to keep the other parties honest.
The third role is the one to protest. This role doesn't have to be played by a tester, but testers tend to be very good at it. The one to protest is the one that looks for hidden assumptions, edge cases, and inconsistencies. She asks "what if this happens", "what else could happen here", or "what other outcomes could occur."
It is very hard to create and criticise at the same time. This is why the one to protest plays such an important role. The early input of engaged testers is invaluable.
Three Amigo workshops need to be fast and fluid. This is why experienced teams use light-weight, collaborative techniques such as Example Mapping and Feature Mapping. Example Mapping is a great way to get a broad picture of the examples and business rules around a feature quickly. And Feature Mapping helps us understand the variations and flows within the scenarios. Experienced teams use a palette of techniques and approaches, in various orders. They learn to know which techniques lend themselves to one feature or another.
TIP: Gherkin is the familiar Given-When-Then format used by BDD tools like Cucumber. In the early days of BDD, we used to write Given-When-Then scenarios during the Three-Amigos workshops. Most experienced BDD teams don't do this anymore. Now don't get me wrong - there is huge value in writing Gherkin scenarios collaboratively as well. But writing the Gherkin syntax during the requirements discovery workshops is time-consuming, and makes it harder to focus on the real business needs or to think in broader terms. For this reason, experienced teams leave the actual writing of the "Given-When-Then" scenarios until after the workshop, and get a pair of the amigos to work on this aspect.
The Three Amigos workshop is a stable of BDD and an important part of agile requirements discovery in general. The practice itself is simple. But it is by understanding the team dynamics behind the practice that you can make it shine.
Take your learning further
Learn how the best BDD coaches run more effective 3-amigos sessions in the BDD Blueprints Training. This online training course will teach you:
- How to run requirements discovery sessions faster (and save time for yourself and for your team!)
- How to find more edge cases and tricky scenarios that would normally only be spotted during development or testing (or even in production!)
- How to eliminate defects before they happen (and bring your unplanned rework right down as well - some teams see defects drop by 80-90% using these techniques)
- How to really master the Given..When..Then notation, so you can use it properly to save you time and effort!
How to make writing automated acceptance tests faster and more reliable (it's VERY hard to do in-sprint test automation without using these techniques)