In the Software Development Process mean — the three primary roles of colleagues involved in production.
Business – represented by role Business Analyst (BA) or Product Owner (PO). The business role provides what problem the team need to solve. They provide requirements for the solution.
The Business Analyst collects the feedback and reviews comments from the team members. Find out missing information and removes the ambiguous information from the Requirement if any.
Product Owner defines Acceptance Criteria, next reviews the test-case, that the test-cases meet to this Acceptance Criteria. Therefore make sure what is being built, matches business stakeholder expectations.
The BA and PO see that everyone in the team has the same understanding and expectation from the User Story, Requirement.
Typically, the business role is non-technical.
Development – represented by Software Developer (Dev), provides 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. Also determination of how the code must be written. It's often likely that certain detail will influence development choices.
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 help predict what could possibly happen.
The tester role must be somewhat technical.
The Development might share their knowledge of technical restrictions which could lead to testing constraints.
Consequently 3 Amigo - 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
See an interesting example of how Three Amigos play roles: Request, Suggest, To protest.
Sometimes is possible to expand the “Amigos group” to 4-5 amigos where necessary. A good example of this being Designers, Digital Marketing Manager they are often a necessary 4th, 5th Amigos they usually come to about 50% of Amigos meetings
Why number 3-4-5 people only? Because such quantity of people (delegated members) will collaborate 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).
As in 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 early Digital Marketing, Design, Creative, Engineering as well. Anywhere there is a need something delivery to clients.
"3 Amigos" Agile session
Three amigos meeting is a way of interacting together, where workshops, brainstorms and especially mapping takes place. It helps make up cool scenarios, develop cool user stories.
Mapping examples can easily be turned into Gherkin scenarios either during or after the meeting.
Three Amigo session is 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
The recommended time is 35 -60 minutes. If takes more time, the story is way too big, need to break it down into a few stories.
Three Amigos applying BDD
The premise of the concept suggests that to really build a shared understanding, need a common way to devise requirements and document them in a manner accessible to both technical and non-technical project members. This is where Behaviour Driven Development and Gherkin Syntax come in. Given-When-Then acts like a receipt for the business role.
Let’s start Behaviour Driven Development from a simple example:
To illustrate let’s take the concept of a simple login form with separate fields such as username, password and a submit button. The first step, try and think of all the scenarios or examples in which a user might interact with this login form. Brainstorm might produce something like this. Referred to as Specification by Example.
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.
Once the team has done an initial brainstorming in terms of scenarios, the next step is to translate these scenarios into Gherkin Languages.
Gherkin Syntax is basically a format for expressing software behaviour using a convention known as ‘Given, When, Then.’ We use this convention when we flesh out 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 examples from earlier.
Scenario 1: 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, hope are you understand implementation?
Tips to get started BDD and write documentation on Gherkin
- 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.
- Three Amigos sessions are more productive if everyone is made home tasks beforehand, read some materials, think about details for stories. Good practice review increments of the product that have been implemented.
- Make decomposition. If you’re moving into the realm of several ‘AND’ statements after a ‘THEN’ statement it’s likely you’ve rolled several scenarios into one. This would be a good time to think about breaking the example down into further scenarios.
- Add and amend as needed. You won’t always think of every scenario upfront. That’s ok. Just remember to keep the team in the loop!
- Without blind fanaticism