What are Three amigos in Agile?

Let's talk about Agile methodology. Three Amigos is a powerful method to stay in the same wave and improve communication breakdown in the team. Many modern Agile teams practice the Three Amigos approach. Using it, they represent exceptional efficiency in delivering quality software.
Mykhailo Poliarush

You don`t know: What are “Three Amigos”? So, you are reading this article. Did we guess? It’s okay. We will try to explain what is “Three amigos” definition quite clearly and shortly. But at first, trust your feeling 💭

You are right, Three Amigos is friends, not enemies in any case. Yeah, this is a partnerships comparison.

In the Software Development Process mean — the three primary roles of colleagues involved in production.

Business – represented by role Business Analyst (BA) or/and Product Owner (PO). The business role provides what problem the team needs to solve. They provide requirements for the solution.

  • Business Analyst collects the feedback and reviews comments from the team members. Find out missing information and remove the ambiguous information from the Requirement if any.
  • Product Owner defines Acceptance Criteria. Next review of the test cases, whether the test cases meet these Acceptance Criteria. So make sure what is being built, matches business stakeholder expectations.

Together BA and PO see that everyone in the team has the same understanding of each User Story and Requirements Specification.

Typically, the business role is non-technical.

Development – represented by Software Developer (Dev). Decides how might build a solution to solve a problem set to the team.

  • For Devs are important to have clarity on the scope of the tasks announced by PO.
  • Also determination of how the code must be written. It’s often likely that certain detail will influence the development process.

The development role must be technical, and highly professional.

Testing Quality Assurance role (QA), verifies that the delivered software product works correctly.

  • QA Engineer looks at context, tries to find defects, always helps predict what could possibly happen.

The tester‘s role must be somewhat technical.

The Development might share their knowledge of technical restrictions which could lead to testing constraints.

Conclusion:

 3 Amigos — method of communication for a delivery quality product.

The key to this is understanding that excellent products don’t stem from a wide group of experts or one individual. But from close collaboration and good organization across different specialists. The voice of the team, have you ever heard about?

Deep into the link, there is an interesting example of how Three Amigos play roles: Request, Suggest, To protest.

Sometimes it is possible to expand the “Amigos group” to 4-5 amigos where necessary. A good example of this will be Designer, Digital Marketing Manager. They are often a necessary 4th, 5th Amigos. They usually come to about 50% of “Three Amigos” meetings.

Why number 3-4-5 people only? Because such quantity delegated members will work more quickly than 13 people.

They are a much more efficient use of time than traditional grooming sessions, which run the risk of extending for hours, involving a large number of people (perhaps even the whole team).

Like an Agile and Scrum, the flexibility and speed in “Three Amigos” are primary.

Also quite difficult to determine “3 Amigos” whether it is a framework, approach, method, strategy or principle. There are a lot of mentions on the internet. “Three amigos” also known as Story Kick-Off huddles or the Triad.

Nowadays, “Three Amigos” is used not only in Software Development. Mentioned in Digital Marketing, Design, Creative, Engineering as well. Anywhere there is a need something to delivery clients.

3 Amigos Agile Session

“Three Amigos” meeting is a major component of the testing process. It is a way of interacting together. On “3 Amigos” meetings workshops, brainstorms and especially mapping takes place. It helps make up cool scenarios, develop cool user stories.

Mapping examples are easy to turn into Gherkin scenarios.

“Three Amigos” sessions are usually conducted in the previous to development Sprint. But, not before because the basic details may change.

It is a shift left practise because we try Test First Development approach.

The recommended time is 35 – 60 minutes. If it takes more time, the story is way too big, need to be broken down into a few stories.

Three Amigos applying BDD

In order to build a really shared understanding, there is a perception to formalize requirements suitable for automation in a manner accessible to both technical and non-technical project members. This is where Behavior Driven Development with Gherkin Syntax comes in.

In the post Behavior­ Driven Development & Agile Methodologies in Quality Assurance we talk about that according to the Agile BDD development process, BA or QA should convert requirements into user stories. They strive to use a more short user story format. Mostly one user story equals one product functionality.

Next 3 Amigos during “Three Amigos meeting” take this user story and think of all possible scenarios of how an application might respond.

Let’s started stydying Behaviour Driven Development from a simple example!

To illustrate let’s take a simple login form example with separate fields such as username, password and a submit button. Brainstorming might produce scope like this.

Participants wrote it on paper or on board:

  • Scenario 1: User enters correct details and clicks submit
  • Scenario 2: User enters the correct username and incorrect password and then clicks submit
  • Scenario 3: User enters incorrect username and correct password and then clicks submit
  • Scenario 4: User clicks submit with empty username and password fields

This list above is not necessarily exhaustive but illustrates the concept of scenarios and their usefulness in terms of thinking about the login story we are implementing.

The point here is to check how the software should behave in each scenario. This is Behaviour Driven Development in action.

Once the team has done an initial brainstorming in terms of scenarios, they need to translate these scenarios into Gherkin Language.

Gherkin Syntax is basically a format for expressing software behaviour using a convention known as “GIVEN, WHEN, THEN”. We use this convention when we describe our scenarios. In abstract terms, it looks something like this…

  Given some initial state
   When an action is performed
   Then this happens

Let’s try this out on one of our bdd test examples from earlier:

Scenario: User enters correct details and clicks submit
  Given I am on the login form
   When I submit my correct username and password
   Then I am logged in successfully
    And I am taken to the homepage

That’s all, we hope, you understand the implementation 😉

Gherkin features usually are written by QA engineers, but anybody from the team can do it as well.

Tips to get started BDD
and write documentation on Gherkin

  • Do not make the “Three Amigos” meeting a formality. We would like to emphasize, the session must be efficient. Don`t waste your time!
  • Don’t artificially limit the meetings to three and only three people. Depending on the feature, you might find that other teammates have valuable input like expertise.
  • Three Amigos sessions are more productive if all participants of “Three Amigo sessions” have made home tasks beforehand. Read some materials, think about details for stories etc.
  • Good practice is to review features that were implemented in the product before.
  • Should make decomposition. If you’re moving into the realm of several AND statements after a THEN statement it’s a “red button” that you were flesh out several scenarios into one. Would be a good thing to break down the user story into further scenarios.
  • Add and amend new elements in the feature file as needed. You won’t always think of every scenario upfront. That’s okay. Just remember to keep the team in the loop!
  • Without blind fanaticism! It makes no sense to implement BDD because this is a trend. The same large number of details in the scenarios or duplicated scenarios are too much.

Testomat.io is a perfect tool to implement the “Three Amigos” principle:

  • Gherkin scenarios could be imported into the Test Management System.
  • You can run both manual scenarios, automated scenarios and receive informative reporting.
  • You can check failed, passed tests, test coverage, metrics based on this report in real-time, filter, tags, compare tests and many more…
  • Test results will be visible to teammates. 
  • Testomat.io provides comprehensive test case management to make decisions for all stakeholders.

Create first BDD project
Turn your Jira stories into BDD features as well as test cases into BDD scenarious 👇
Follow us