3 Amigos

Description

To prepare for the next sprint, the Product Owner (PO) organises, possibly with the help of the Scrum Master, meetings called "Sprint Refinements" where he presents the User Stories (US) to certain members of the team in order to facilitate sprint planning.

The danger of involving only developers is that they will focus on modelling the technical solution to be provided once they have understood the objective of the US presented with little attention to the acceptance criteria.

The practice of the "3 Amigos" consists of inviting to the refinement Sprint a Developer to spot how the US would be implemented and another actor from the development team who can identify the most relevant acceptance criteria. To do this, a Tester or any other person capable of decentering to the "how" problem is necessary. This extra person must provide insight into the use of the US, both in terms of the proposed functionality and its exploitation.

This person's questions should lead to :

• The PO to identify the answers, specify the test data involved in these questions and the level of added value seen from the field associated with these questions so as to provide the underlying requirements for the US
• The Developer to integrate these functional requirements and those that have an impact on the architecture, this is the notion of "Architectural Significant Requirement" [Moustier 2019] [ASR 2021]

‍It can be noted that this workshop can be enriched by adding different profiles (UX, security, customer, ...) [Hage Chahine 2020] [Moustier 2019].

Application to test maturity

When ideating a US, it is essential to keep in mind the ISTQB principle "Tests depend on the context" [Radid 2018-6]. This focus on implementation allows for the identification of :

• The nominal and most critical of the rare use cases, if not all of them can be tested [Radid 2018-2], these examples that will serve as requirements whose data will enable explicit test cases or acceptance criteria for the US that can then help to eventually cut the US if it becomes too large to be done in the sprint.
• Non-functional requirements tests

‍

Most of these tests will then be automated to allow each team member to check that they have not introduced any regression with each new US introduced into the product increment.

Agilitest's position on this practice

The design of automated test scripts should not be done in isolation in order to avoid designing a script with little added value or with things that will be quickly rendered obsolete by updating widgets or business processes.

Thus, knowledge of changes in the upcoming sprint can be valuable information for possibly questioning the added value of an automation or designing its script in such a way that it will remain operational with the planned change.

‍

To discover the whole set of practices, click here.

‍