Three Amigos and a Generative AI Assistant

Introduction:

The rapid advancements in generative artificial intelligence (AI) have opened up new possibilities for streamlining software development processes. One such opportunity lies in integrating AI assistants into the collaborative Three Amigos meeting, a key practice in Agile methodologies. The Three Amigos meeting brings together the business, development, and testing perspectives to align on requirements and implementation details before development begins. By leveraging the capabilities of a generative AI assistant like Amazon Q for Developer, teams can capture requirements in an executable format, promoting a shared understanding and accelerating the delivery of high-quality software. In this blog post, we'll explore how to use Amazon Q to generate Behaviour-Driven Development (BDD) artifacts directly from the Three Amigos meeting dialogue, showcasing the potential for AI to bridge the gap between business and technical stakeholders.

Three Amigos:

If you are into agile software development you may have heard of the Three Amigos meeting.

A Three Amigos meeting is a practice in Agile software development where the key stakeholders - a business analyst/product owner (representing the business perspective), a developer (representing the technical perspective), and a tester (representing the quality perspective) - collaborate to discuss and align on the requirements, implementation, and testing approach for a user story or feature before development begins.

The main goals of a Three Amigos meeting are:

Ensure a shared understanding of the user story/feature among the three perspectives.
Identify potential risks, edge cases, and acceptance criteria early on.
Discuss and align on the implementation approach, including any technical constraints or dependencies.
Determine the testing strategy, including what to automate and what to test manually.

Behaviour-Driven Development (BDD):

Behaviour-Driven Development (BDD) can be effectively used in conjunction with Three Amigos meetings to facilitate the discussion and capture the requirements in a structured, executable format. Here's how BDD can be integrated into the Three Amigos meeting:

Discuss the user story/feature: Start by reviewing the user story or feature from the business perspective, ensuring everyone understands the problem being solved and the expected behaviour.
Identify scenarios and examples: As a group, identify the key scenarios and examples that illustrate the desired behaviour of the feature. These scenarios can be expressed using the Given-When-Then format of BDD, which helps to clarify the context, actions, and expected outcomes.
Write executable specifications: The tester or developer can capture the scenarios and examples as executable specifications (e.g., using a BDD framework like Cucumber, SpecFlow, or JBehave) during the meeting. This ensures that the requirements are documented in a clear, unambiguous, and executable format.
Review and refine: The group can review and refine the scenarios and examples, ensuring that they accurately capture the desired behaviour and cover all edge cases and acceptance criteria.
Discuss implementation and testing: With the scenarios and examples in place, the group can discuss the implementation approach, identify any technical challenges or dependencies, and determine the testing strategy, including what to automate using the BDD scenarios and what to test manually.

By incorporating BDD into the Three Amigos meeting, the team can ensure a shared understanding of the requirements, capture them in an executable format, and align on the implementation and testing approach. This collaboration helps to reduce misunderstandings, identify potential issues early, and promote a shared responsibility for the quality of the software.

The Experiment:

To showcase this, I have mocked a simple transcript of a typical three amigos meeting.

Based on the transcript the aim of our experiment is to use Amazon Q for developer to generate tangible outcomes such as a feature files, the base of a Behaviour-Driven Development.

Here is the transcript of the three Amigos meeting

Product Owner: Hi Team, thank you for arranging this meeting. I am really excited as the funding to kick start this project has been approved by management, and we can start of this meeting going through some thoughts I have.

Developer: Great news. Can you tell us more about this application that you want us to build?

Product Owner: It is a simple application that allows users to purchase concert tour tickets online. When a release date for a new concert is announced, we would like to sell the tickets online. Let's say the sales window opens a few months before the artist's tour dates. The user should be able to pick their date and buy tickets.

Developer: Great! How many tickets can a user buy?

Product Owner: I think the maximum allowed tickets should be 4. But can we keep it configurable just in case this number changes in the future?

Developer: Of course. That can be done.

Tester: Should we take the limit as 4 for this phase of testing the application with a test case to see if this can be increased or decreased through configuration?

Product Owner: Yes, that would be a good start, but make sure that we never set the configuration below 1. So if a customer is in the queue, they will need to purchase 1 to the maximum allowed ticket. If they wish to quit, they can just type "quit" to exit the queue.

Developer: Tell us more about this queue. Are we making a virtual queue for customers to join online?

Product Owner: Yes, when the online sales window opens for a tour, we allow customers to join the back of the queue. We let the user know their position and let them track as their position changes. When they get to the front of the queue, they can buy the tickets.

Developer: Got it, this is going to be a bit difficult to test.

Tester: Can you create a Queue Simulator to test this?

Developer: Yes, we can do that. We can create a simulator that accompanies this application to test it. The simulator can assign a random position to the customer, initially keeping it between 1-10. We can also simulate the customer moving up the queue by one position every 10 seconds. We can keep both the values configurable, of course. As the customer moves up in the queue, we can display their current position. And when it's the customer's turn, they can purchase the tickets as discussed earlier.

Tester: What should happen if the customer enters an invalid number of tickets, for example, more than the maximum they are allowed or any other incorrect value?

Product Owner: Display an error message letting them know what the valid value is.

Tester: How many times will we allow them to enter incorrect values?

Product Owner: Maybe 3 times, after which they will be dropped from the queue. But do warn them when it is their last chance to enter a correct value.

Developer: Ok, Great. Let us start working on it. I can use Java 20 and use BDD using Cucumber and Gherkin to write these features. Let me first write the feature files and validate them with both of you before we proceed.

As you can see the transcript is captured in a dialogue format and in simple English. It uses common software paradigm. This is where we leverage a AI assistant to codify this everyday language in the form of feature files.

I used a powerful feature of Amazon Q Developer "/dev" an Agent for software development and feature development. Below is the prompt to Amazon Q for Developer in the IDE (IntelliJ) to generate these feature files.

1
2
3
4
5
6
/dev Given the below transcript using cucumber and gherkin language create features files.
Product Owner: Hi Team, thank you for arranging this meeting. I am really excited as the funding to kick start this project has been approved by management, and we can start of this meeting going through some thoughts I have.
(Above transcript continued)
.
.
.

Based on this prompt Amazon Q creates an implementation plan

Here is the response from my prompt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Okay, I'll generate code for that. This might take a few minutes.

You can navigate away from this chat, but please keep this tab open. I'll notify you when I'm done.

Generating code ...

I'll share updates here as I work on this.

**Summary of changes**

1. I will open relevant files to explore the workspace and identify where to add new feature files for the concert ticket purchasing application. Since no files are currently open, I'll start by opening the pom.xml file and searching for relevant directories that may contain feature files.
    
2. Based on the pom.xml file, I can see that this is a Maven project with Cucumber dependencies. I will now open the src/test/resources folder to look for existing feature files or to determine where new feature files should be added.
    
3. The src/test/resources folder doesn't exist, which means we need to create it along with the feature files. I'll create the necessary directory structure and the first feature file for the ticket purchasing system.
    
4. I have successfully created the ticket_purchase.feature file with scenarios covering the main requirements. Now, I will create another feature file for the queue simulator functionality to complete our feature set.
    
5. I have created two comprehensive feature files: ticket_purchase.feature and queue_simulator.feature. These files cover all the main requirements discussed in the conversation, including ticket purchasing, queue management, and the queue simulator for testing. As all the necessary features have been defined, we can now move to the next phase.
    

**Files used**  
_These fields can change throughout code generation_

- Reviewed: 1
    
    - pom.xml
        
- Created: 2
    
    - src/test/resources/features/ticket_purchase.feature
        
    - src/test/resources/features/queue_simulator.feature
        
- Changed: 0
    
- Deleted: 0

Using the information provide in the transcript and using aspects of the prompt Amazon Q for developer suggest creation of 2 feature files.

Note: It is important to pause at this point and review the plan. you can request changing the plan if this doesn't work for you.

Once you accept the plan it will generate the code. Here is the suggested cod. See screenshot

Image not found

Code Suggestion

You can click on the individual feature files before accepting them. And Amazon Q will add this to you workspace.

Remember this is a great starting point to go back into a three amigos team to agree up on the codified requirements as you would in a regular agile ceremony.

Result:

Here is the content that is generate by Amazon Q for me. (Remember generative AI is nondeterministic and results may vary for you)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Feature: Concert Ticket Purchase

Scenario: Join the queue for ticket purchase
  Given the online sales window is open for a concert tour
  When a customer joins the queue
  Then they should be assigned a position in the queue
  And they should be able to track their position

Scenario: Purchase tickets when at the front of the queue
  Given a customer is at the front of the queue
  When they choose to buy tickets
  Then they should be able to select between 1 and 4 tickets
  And complete the purchase

Scenario: Attempt to purchase more than the maximum allowed tickets
  Given a customer is at the front of the queue
  When they try to purchase 5 tickets
  Then they should see an error message
  And be prompted to enter a valid number of tickets

Scenario: Enter invalid ticket quantity multiple times
  Given a customer is at the front of the queue
  When they enter an invalid ticket quantity 3 times
  Then they should be warned on the third attempt
  And be removed from the queue after the third invalid entry

Scenario: Quit the queue
  Given a customer is in the queue
  When they type "quit"
  Then they should be removed from the queue

Scenario: Configure maximum allowed tickets
  Given the system allows configuration of maximum tickets
  When the maximum ticket limit is set to 6
  Then a customer should be able to purchase up to 6 tickets

Scenario: Attempt to set invalid maximum ticket limit
  Given the system allows configuration of maximum tickets
  When trying to set the maximum ticket limit to 0
  Then the system should reject the configuration
  And keep the minimum limit at 1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Feature: Queue Simulator

Scenario: Initialize customer position in queue
  Given a new customer joins the queue
  When the queue simulator assigns a position
  Then the customer should be assigned a random position between 1 and 10

Scenario: Move customer up in queue
  Given a customer is in position 5 in the queue
  When 10 seconds have passed
  Then the customer's position should be updated to 4

Scenario: Configure initial queue position range
  Given the queue simulator is configurable
  When the initial position range is set to 1-20
  Then new customers should be assigned a position between 1 and 20

Scenario: Configure queue movement interval
  Given the queue simulator is configurable
  When the queue movement interval is set to 15 seconds
  Then customers should move up the queue every 15 seconds

Scenario: Display current queue position
  Given a customer is in the queue
  When their position changes
  Then the customer should see their updated position in the queue

Scenario: Reach front of queue
  Given a customer is in position 2 in the queue
  When their position is updated
  Then they should be notified that it's their turn to purchase tickets

In fact done write the capturing , codfying, reviewing of the requirement into feature files can be done as a part of the same meeting saving important time.

Once agreed the feature files can be checked in into your code repository such as Git.

This becomes then a starting point for developer to go and develop code against.

In the next part of the series of this blog we will take these feature files into the next logical step. Of course using Amazon Q for Developer.

Conclusion:

The blog post showcases the integration of an AI assistant, Amazon Q for Developer, into the Three Amigos meeting and the BDD process. By generating feature files from the transcript of the meeting, the author demonstrates the potential for AI to assist in the early stages of the software development lifecycle, helping to capture requirements more efficiently and align the team on the desired behaviour of the application. This approach can help reduce misunderstandings, identify potential issues early, and promote a shared responsibility for the quality of the software. The blog post suggests that this is just the beginning and that the next step will be to take these feature files and continue the development process using the AI assistant.

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Select your cookie preferences

Site Terms, Privacy, and more.