3 Amigo - a way to communicate, to create a quality product

Imagine a situation - the tester finds a bug, begins to discuss it with the developer - and he insists that this is not a bug, because the specification did not talk about this functionality. Familiar?

Or because the requirements were ambiguously formulated, and he misunderstood them. Or, on the contrary, there was so much information in them that the focus was lost and some of the information was lost sight of during development.

And in this situation, the developer is not a pest who was specifically mistaken. In practice, if you give it simple, understandable and, most importantly, short requirements - the number of errors that testers will find will go to zero.

You are also probably familiar with the controversy on the subject of "this is a bug or feature." Customers found flaws, and the product owner comes to the team with comments. And the tester and the developer are protected, explaining that in the original formulation there was no talk of implementing this feature. And these moments then turn up in the backlog.

I believe that all such tasks, instituted after the release, and resulting from a poorly designed specification, are also bugs. The bugs that characterize the quality of your product.

It turns out, business analysts determine which features to create. Developers create them. Testers find defects in the work of both. This is the traditional approach to development. But you can teach these three to cooperate in order to do their job better and immediately, without additional alterations. And this way of communication is called 3 Amigo. Also called Story Kick Off Huddles or Triad.

3 Amigo is ...

3 Amigo is a practice that gives a general understanding of what will be delivered to the client. Helps to convey the voice of the team, and not the interweaving of disparate opinions.

This method of communication within the team helps:

• come to a general agreement on expectations before starting development
• form an agreement on how to do the right thing right away

And also, promotes understanding:

• what problem do we solve
• what are the solutions
• what we need to do to make the task ready

Meeting the three amigos is a way of collaborative thinking that eliminates gaps in the understanding of business specifications. It helps in developing cool user stories.

The goal is to do the work on time, but at the same time plan not so in advance that the parts have time to become obsolete.

Why 3? Who do you apply?

The name of the practice does not limit us to three contexts, but only creates a minimal framework. To make sure that the development of requirements took into account all the technical nuances, explicit and implicit cases, that the specification reflects the actual needs of the client - 3 different thinking / contexts are required: business, developer, tester. In this meeting is not limited to these people. It involves all who are involved in the implementation of the requirement. For example, if your task contains not only web, but also mobile, then an additional context is needed. That is, the person who will do the implementation in a mobile application. In our teams, 4 developers (1 ios, 1 android, 1 back, 1 front), a tester and a business analyst participate most often in a meeting.

Business analyst or PO

A business representative knows (almost always) what he wants to get in the end and what value the client and business will receive from this. It is important to talk about this team.
By participating in the meeting of 3 Amigo, the business analyst shares information with the participants so that everyone on the team has the same understanding and expectation from the user story. Also, only he can limit the scope of acceptance criteria, which then will be accepted.

Developers

The developer knows how to realize the requirement of the business, what are the opportunities for this. As a rule, he thinks about the details that he needs to know in order to proceed with the implementation. By asking questions based on his experience and knowledge of the system, the developer helps to reveal the various nuances at the discussion stage of requirements.

Tester

The tester, as well as other team members, helps to enrich the requirements with various test cases. Based on his experience, he more and more often questions any statements the team voices. Therefore, it is better to find extreme cases, implicit scenarios, wonders what can go wrong, what to watch out for.

When practice is applied?

I rarely met the development process where requirements testing was explicitly present. In most cases, the requirements began to be studied during the development or testing phase, and only then were any inconsistencies revealed.

An untested specification is likely ambiguous, contradictory, incomplete, duplicated, and sometimes even outdated requirements. This is because everyone understands what has been read and heard in his own way. From here there is a discrepancy in interpretation.

And if the documentation is large and detailed, then its reading may take longer than the testing or development process itself.

In our business line, we decided to apply this practice when tasks began to linger in testing. We identified 3 main problems:

1. At the testing stage, there were many returns due to clarification of requirements. These were tangible pauses in testing and development, when the business analyst determined how to work.
2. Task testing was delayed due to overly detailed specification. Cases were frequent when the tester could spend 3-6 hours only to study the requirements and test cases, and the testing itself took about 30 minutes. And the most egregious was the case when they started testing after 2 weeks of studying the specification, so difficult it was and detailed.
3. Well, the most common problem was that during acceptance testing there were a lot of bugs. Those bugs that could have been avoided if they had been thought of before development.

It turns out that despite the agile development, there is still a stage of work with technical specifications. And if they didn’t take any cases into account, because the customer didn’t say about them, or they didn’t do what he really meant after the product was released, he backed up a bunch of tasks to refine or even rework.

And finally, it should be voiced and the problem with the assessment.
It is difficult to assess the task when you do not really understand the whole amount of work that is to be done on it. How many tests to write, how many returns will be due to bugs or alterations due to inaccurate specifications? Even if the developer gives an accurate estimate of the development time itself, you almost never guess how long that unpredictable testing phase will take.

AC Practice Practice Steps

1. We formulate requirements as User Story

I recommend applying the requirements based on user stories. And as a basis to take one story and at the meeting 3 amigo to work only on it.

Here, a very important point is that the demand from the business is really formulated as a user story. That is, kept in itself 3 parts, namely:

I, as a <role>, want <action> to <motivation>

This is actually the most popular template for the formation of user stories and is called Connextra. There are also other templates, but I recommend using this one. And why, now I will explain.

Traditionally, there are 2 problems in the formation of a user story:

• When recording, either do not indicate the role, leaving the action and motivation
• Or they indicate the role and the action, and the motivation is discarded.

It actually causes problems, and I will try to explain with simple examples which ones.

1. Knowing <role>, you as team members will better understand the limits of acceptance criteria that you need to form. Not until the end of the understanding of the person concerned in this user story, you can either do it beyond what’s needed, or, on the contrary, do some functionality.
   
   • Example : the team did not understand the role in the user story, and when working on the problem, decided that she would do 3 methods for api: add, edit and delete. And on the front will add a button that will call these methods. When they presented their decision to the business, they received feedback that their client is actually a specific business analyst who can use the add method. And it will not be deleted and edited. And he can call this method through postman.
2. The team does not understand the motivation of the “role” for whom they make a user story. Because of misunderstanding, the boundaries of the user story itself are poorly outlined. And besides this, the acceptance criteria as a result may not solve the final client problem, although they will correspond to the action that was voiced in the user story.
   
   • Example : the team took the user story into work, where the business analyst could not clearly articulate the motivation. On the one hand, she was to leave the client loyal and make improvements for him. On the other hand - reducing costs for the bank. In this case, the methods of implementation and acceptance criteria were radically different. Because in the first case, the team focused on user acceptance criteria. In the second - the team paid attention to how to make the most simple and fast implementation.

But the formulation in the above format is not a prerequisite. I know teams that conduct meetings in Amigo 3 format and without a user story. And as the basis of use TK. In this case, its pitfalls arise, but it was a conscious choice of the team.

Meeting 3 Amigo begins with preparation. As part of preparing for it, the requirements are formulated so that they are understandable to the whole team. These requirements are validated for availability.

Validation includes the assessment of history by the criteria of INVEST. As well as the quality of the wording of the story itself. This excludes any ambiguity, verbosity, and when evaluating for INVEST, particular attention is paid to the size of the story. If the team understands that the requirement is epic, then decomposition occurs.

After the requirement has passed the stage of transformation into a user story and validation by the team (3 amigos), you can begin to work out the acceptance criteria.

2. We supplement the acceptance criteria to the User Story at the meeting of 3 Amigo

First you need to decide what the acceptance criteria are all the same.

So, acceptance criteria are requirements from the customer; specification on which the system / user story can be checked.

They have an alternative name, conditions of satisfaction - conditions for meeting expectations (by Mike Cohn).

At the meeting of 3 Amigo team already comes prepared. They already have a validated user story, which may already have some sort of acceptance criteria, which the business representative has formulated independently.

During the meeting, the tasks of the participants to add / enrich the history with a sufficient number of acceptance criteria for its subsequent implementation.

Acceptance criteria should not include implementation details. In fact, acceptance criteria are business rules that govern a user history under study. Implementation details are recorded in acceptance tests, but after all acceptance criteria have been formulated.

You should not mix implementation details with acceptance criteria at least because with limited deadlines, you as a team can always “throw out” some scope of criteria that are not so important for business in the near future. If there are details with technical implementation in the criteria - you risk losing important information and time that has already been spent discussing the details of implementation. Your implementation details are directly dependent on the scope of the criteria you need to do.

Also avoid a consistent description of the scenario with a set of steps (the classic system of conducting test cases). Your every statement must be atomic. It is better to use the descriptive style of the expected behavior of the function being created.

For example:

*     ,     .*> 

3. We maintain timing

A well-decomposed US generally does not contain more than 10 acceptance criteria. If in the process of discussion a large number of acceptance criteria is found and all of them are subject to realization, then this history should be decomposed into several stories with a different pool of acceptance criteria.

If this is not done, then the meeting of 3 Amigo will be greatly delayed.

The optimal time for a meeting of 3 Amigo - from 30 minutes to 1 hour.

An increase at the very beginning of the path is acceptable - when a team is just learning to communicate and apply this practice.

If a team takes a big story to work, then it is unlikely that in one session they will be able to work out all the criteria and acceptance tests. Because the focus and attentiveness is lost. In this case, you need to divide the session into several meetings. But in this case there is a risk of losing the context, and additional diving may be necessary when re-meeting.

4. For completeness of the criteria we apply USR heuristics.

When I teach commands to this practice, I recommend using heuristics at the very beginning of their journey to smooth out their lack of experience. With experience, the team has its own heuristics and checklists of what to look for when working out the criteria.

Heuristics USR allows you to consider the criteria at all levels that are needed in order to get maximum information about what the customer wants.

So,

1. USER - What does the user want to do with the system?
2. SYSTEM - What should the system do?
3. RISKS - What problems might arise?

It is important to first work out all the criteria of the USER group, and then only go to the system level. This includes front and backend developers, and at the level of their systems they can formulate acceptance criteria for what should be possible in order to implement the criteria from the USER group.

Finally, the RISK group. About her most often forget about the elaboration of requirements, although it is no less important. Here are considered various complex cases that you probably will not implement. But talk and take risks as a team - are required.

Ways to practice for the development of test cases prior to development

The recommended way to formalize requirements is examples of use, in Russian IT we call this test cases.
There is a handy tool for developing test cases at a meeting of 3 Amigo, called example mapping. In this article I briefly touched it. In the next article we will publish detailed information on this tool and how it is used in the framework of the triad meeting.

Test cases can be implemented as automated history acceptance tests. Also, when you are working on test cases, be sure to group them. Splitting test cases into groups is a way to divide the story into several smaller ones.
In test cases, the decomposition of a business rule occurs at exactly the system level at which they will be implemented, and not by the user.
All details of the implementation should be in your test cases, so that they are the orientation of the developers in the implementation process.

How it might look in the overall process (when you need to hold this meeting)

It is recommended in the framework of one meeting to work out the requirements for only one user story. Allowed more, provided that these are very small stories or they are related to each other in meaning.

Since in the sprint you take stories that are already ready for work, the 3 Amigo meeting on history should be held before planning. Otherwise, you risk a big mistake with a preliminary assessment. In practice, the evaluation of the story after meeting 3 Amigo is very different from the original.

Also, it makes sense to add a new item to the DOD as an indicator of readiness, that the story is ready to work on it in the sprint.

For example, we have some teams that have begun to apply this practice, agreed that they will not take the planning in the sprint, if the task does not have acceptance criteria and acceptance tests.

And on the sprint review, history acceptance is presented by acceptance criteria.
But at the same time, the meeting of 3 Amigo also fits into the process, if the team is working and not on a scrum, but for example using kanban. In this case, the task gets into development only after having passed through the meeting of 3 Amigo.

What is the result at the exit of the meeting 3 Amigo?

• scripts / examples (obvious answers)
• revised rules / acceptance criteria
• new / decomposed stories
• general understanding of the problem area
• empathy (empathy, participation)

The main results of the three amigo are the acceptance tests, written in the “ Given / When / Then” format. In fact, their writing may take more time than we would like, therefore, it is not recommended to formalize all requirements at a meeting when everyone is together. Usually the developer or tester works on this outside the meeting. And as soon as they have all the criteria and test cases are recorded, 3 Amigos briefly review what happened to make sure that everyone agrees with what was recorded.

Profit of using the practice of 3 Amigo

Strategy 3 Amigos can have a huge impact on the effectiveness of the whole team, as well as on the quality and sustainability of your projects, increasing agility, flexibility to change.

Here are some more bonuses:

• When planning, we do not spend a lot of time diving into the meaning of history.
• Identifies confusion and misunderstanding at an early stage, which allows for faster delivery.
• Ensures that the team will discuss the required scope of work.
• Helps find all acceptance criteria and other quality attributes
• Developing test cases is much easier.
• We provoke developers to cover the code with tests
• Faster we conclude that this feature is not needed

Our teams, by applying the practice, were able to come up with a reduction in task returns due to inaccurate specifications. The guys learned how to develop backend tasks "from the first time." That is, without bugs and immediately on the prod.

Underwater rocks

• Do not be limited to only three people. If you need more - call.
• Do not hold a meeting for the whole team. In this meeting there should be a minimum number of people to implement the features.
• Do not consider as a regular meeting - a ritual. Otherwise, the team will be negative from the increase in the number of meetings.

Master Class at the QualityConf Conference

On May 27-28, at the RIT ++ festival at the QualityConf conference, I will hold a master class on working out requirements using the Amigo 3 practice.
If you are interested in the approach and you have questions, you can also contact me in the telegram @Travieso_nastya.

Approach history

Author of the approach: George Dinviddi, 2009.

He described this approach in his interview and mentioned in a number of articles, references to which I attached. Also, as an additional material, I attached all the links to the English-language resources, according to which I studied this practice and learned to apply it.

https://www.agilealliance.org/glossary/three-amigos/

https://www.infoq.com/interviews/george-dinwiddie-three-amigos

https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories

https://www.stickyminds.com/better-software-magazine/three-amigos