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.

Based on this prompt Amazon Q creates an implementation plan

Here is the response from my prompt.

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

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)

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.

Site Terms, Privacy, and more.