What are Three amigos in Agile?

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 are friends, not enemies in any case. Yeah, this is a partnership comparison.

In the Software Development Process mean — the three primary roles of colleagues who are involved in software development process.

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

• Business Analyst collects the feedback and reviews comments from the other team members. Find out missing information and remove the ambiguous information from the Requirement if any.
• Product Owner defines Acceptance Criteria. Next review the test cases and whether the test cases meet these Acceptance Criteria. 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.

• Quality Assurance team elaborates on test artifacts such as test cases, check lists, test plan etc. These are their key duties.
• QA Engineer looks at context, tries to find defects and always helps predict what could happen.

The tester‘s role must be somewhat technical.

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

Conclusion:

 3 Amigos — method of communication “being on the same page” 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 impact of team voice, 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 would be expanding with a 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 team 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 by involving a large number of participants (perhaps even the entire team).

Like 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 are the needs something to delivery clients.

3 Amigos Agile Session

The “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 think up cool test scenarios and develop cool user stories.

Mapping examples are easy to turn into Gherkin scenarios. It is an advantage.

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

It is a shift left practice because we try the Test First Development approach. To find out more detail, please follow the next article on this testing blog Shift Left & Shift Right approaches in Software Testing 

The recommended time of the Agile sprint planning session is 35 – 60 minutes. If it takes more time, the story is way too big and needs 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 how 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 the “Three Amigos meeting” take this user story and think of all possible test scenarios of how an application might respond.

Let’s start studying 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 the 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.
• A 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 Feature file or duplicated test scenarios are too much.

Meet 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. 
• Test management solution testomat.io provides comprehensive test case management to make decisions for all stakeholders.

⏩ Watch the DEMO conducted by our CEO Mykhailo Poliarush