Introduction to 3 Amigo Principle:
Previously in the Scrum Series, we introduced you with the concept of bringing self-sufficiency within the Scrum Team members to induce the culture producing business value without requiring any help from the outside world.
Lately, I was aligned with a Client Project where I worked as a Scrum Master. Having worked in multiple Scrum based Projects, I was successfully able to blend the methodology within the Client’s ways of working.
However, after a particular period of time, a lot of vagueness was found around the requirement of understanding.
Every Scrum Team Member has his own version of the Requirement understanding!
Table of Contents:
Overview
What would happen if the Developers and the QA’s have two different perspectives of the same requirement?
The obvious course of action, in this case, will be that the Developers would develop the Increment keeping their perspective in mind whereas the testers would test it keeping their own perspective in mind.
The two perspectives tend to create a gap and issues are then addressed only towards the end of the Sprint. An even worst case would be if no time is left to address these issues within the Sprint landing us in a situation to add additional items in a Product Backlog.
In order to resolve the above problem statement, we came up with a solution to have more requirement discussion sessions amongst the team members to analyze and brainstorm over the requirements as a whole. And hence the idea of the Three Amigo Principle came into light.
Before jumping on to the Three Amigo Principle, let us first discuss one of the Agile Testing Practices, Test First Development (TFD) and how it is associated with The Three Amigos.
Test First Development (TFD)
As the name itself suggests, Test First Development is a practice where the test cases are written by the Test Engineers prior to any development activity.
These test cases are then discussed and shared across the entire Team. The team members now get into a meeting to discuss, enhance and review the test cases (also referred to as ‘The Three Amigos’). The edge cases are also added to the list of Test cases during this meeting.
We may also include the Product Owner to add and review the test cases which would build a confidence that the test cases meet the Acceptance Criteria.
Now that the test cases have been developed, the entire development would be based on these test cases. This phenomenon is also known as the test-build cycle. Within a test build cycle, build until all the test cases are passed leaving no space for bugs to be existing in the system.
The Test-First Development allows the developers to build an increment which meets the Acceptance Criteria and has a buy-in from the Product Owner (voice of the Customer).
Nowadays, the teams have started adopting the Test Driven Development (TDD) approach and framework which is the next step to Test First Development. Tools like Cucumber, Gauge, Specflow etc. are amongst the most popular ones.
The Three Amigo Principle
Who are the three Amigos?
The three Amigo Principle says that the three Amigos; Business Analyst, Developers and Quality Analysts should get together in a meeting where:
- The Business Analyst details out each of the Business Requirements with the team.
- The members of the Quality Assurance Team discuss the Test Cases already created for these business requirements.
- The members of the Development Team discuss the architecture and the low-level design with the team.
The objective of the three Amigo meeting is to bridge down the gaps in the understanding of the Business Specifications by three Amigos.
The Business Analyst makes sure that everyone in the team has the same understanding and expectation from the Business User Story/Requirement. The Business Analyst collects the feedback and reviews comments from the team members. He/She also adds the missing information and removes the ambiguous information from the User Story if any.
Since the health of the software is always measured by its high-quality standards, the quality assurance team elaborates on the functional and non-functional aspects of the software increment and details out the test cases identified to test the Increment. They also make sure that all the Acceptance Criteria are met by the test cases.
The other team members help in enriching the test cases by finding edge cases and missing scenarios. The members of the Development Team will share their knowledge technical restrictions which could lead to testing constraints.
The developers discuss their understanding of the requirements and what it takes to build the Increment. They would also discuss the Architecture layout and Low-Level Design with the team to form a common understanding of what is going to be built.
The overall outcome of the Three Amigo session is that the entire team has a common understanding of what they are going to build as a part of the next sprint.
Three Amigo Process
The Three Amigo Process constitute the below:
#1) Participants
One representative from the Development Team and Quality Assurance Team each and the Business Analyst. It is suggested to have these representatives, the people who are actually going to work on that requirement to leverage the maximum benefit of the concept. Others like Architects etc. are always welcome to join the meeting and provide their guidance.
#2) Timelines
Three Amigo session is usually conducted in N-1 Sprint. It is also a timed boxed event i.e. they cannot be extended. The recommended time box for the session is 1 hour which is also its maximum duration.
If the feature is to be developed in Sprint N. Then it is highly recommended to conduct the Three Amigo session in N-1 or N-2 Sprint.
#3) Format
#1) The meeting starts with the Business Analyst presenting the requirement to the attendees along with the design documents or wireframes. The Business requirement is expected to be well prepared and documented. It is expected from the team to have gone through the requirement already prior to the meeting.
#2) As a next step, the attendees will be reviewing the requirement and providing feedback which will later be incorporated by the Business Analyst. The attendees will also point out to the ambiguities and gaps if any. The Business Analyst is also expected to remove the ambiguities and fill in the gaps in the requirement.
At times there may be situations, where the Business Analyst may need to confirm queries posted in by the other attendees and may not directly incorporate that review there itself.
#3) Once the requirement is groomed enough and the attendees have no more feedback or open questions, the requirement is marked as ‘Ready’.
#4) Next, the test cases are presented to the Attendees just like the requirements. Test cases are expected to be well-formed and prepared already.
#5) The attendees will now be reviewing the test cases and providing feedback. The QA member will incorporate all the suggestions provided. The Attendees would also point to the missed test cases and the edge case scenarios. The main objective here remains that the test cases should meet all the Acceptance Criteria and have a good test coverage.
#6) The next step is to look at the dependencies and pre-requisites that might have come out during the session.
#7) The dependencies are determined and the action items are created and assigned to the relevant team member. Similarly, the tasks for pre-requisites are created and assigned.
#8) All the artifacts (Requirement, Test cases, tasks, dependencies) mentioned above should be kept in a Project Management Tool like JIRA so that everyone can easily access them.
#9) If there are too many review comments, the Business Analyst and the Quality Assurance Engineer may choose to incorporate them after the session.
Conclusion
In this tutorial, we introduced you to the concept of The Three Amigo Principle which has proven to be very beneficial for delivering the right solution at a faster pace with strong feedback loops.
The three Amigo session leaves no space for having a different understanding of the same requirement. The objective of the meeting is to bring everyone on the same page and then let them accept the requirement before jumping on to the development phase.
If you are already working in the Agile Framework, then I would highly recommend to try and have a couple of The Three Amigo Session and observe the change for yourself.
Our upcoming tutorial will explain more about Scaled agile framework!