In an Agile team one of the goals is to get people talking about their ideas for an item. Many times a user story tells the whole story along with some acceptance criteria. Other times there maybe something that need some clarity. When things are murky or we think that we may not understand completely to start development we can have a Three Amigos meeting.
A Three Amigos meeting involves mainly three people, the developer, the Quality Assurance and the Business Analyst. Some teams may include others in their Three Amigos meetings, such as Product Owner, Scrum Master or other team members. The idea is to get them all in a room and talking through the user story. The Three Amigos meeting is to discuss a user story that is on the Product Backlog.
Timebox the Three Amigos meeting (30 minutes to 1 hour, max). Schedule it to occur one to two sprints before a feature is expected to go into development. Invite the BA, developer, and QA; these will be the individuals who will analyze, develop, and test that feature. (From Scrum Alliance)
To start the meeting the Business Analyst can introduce the user story and explain why this story is needed. The other two members can provide feedback and begin the discussion about the user story. The Quality Assurance team member can present test scenarios to help clarify their understanding. The goal of this meeting is to get this Sprint ready. You may have to have multiple Three Amigos meetings for the same story to get it ready for the Sprint.
The primary outcome of the three amigos are acceptance tests written in Given/When/Then format. Actually writing these out can take a little time, so we don’t do that with everyone sitting in a room. Typically a developer or a tester will work on it outside of the meeting, and once they have the scenarios all written out, then we do a quick review with everyone else that was involved in the original three amigos meeting to make sure that we all agree with what was produced. (From Jon Kruger)
The main benefit is getting everyone on the same page. Many times requirements are written from a perspective of the Business Analyst and may leave out details that can help the developer understand what is needed from a technical perspective. Quality Assurance may have other questions about how to test and what portions of the application need testing.
If you enjoyed this please share this and don’t forget to subscribe to our newsletter.