The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team. The overall aims are to ensure:
i) COLLABORATIVE REQUIREMENTS: a common understanding of what needs to be built, business justification is conveyed for a feature, a project-wide sense of ownership.
ii) COLLABORATIVE TESTS: all teams members contribute to testing the quality of a feature, business & technical edge cases are identifed, testing restrictions are conveyed, test duplication within the team is reduced.
iii) READY FOR DEV CONSENSUS: Pull vs Push approach - features are pulled into a Sprint when they have been reviewed and accepted by the 3 Amigos. Features cannot be pushed into a Sprint – this reduces the risk of the team incorrectly assuming that a feature is ready for dev.
The general format of the 3 Amigo process is:
A time boxed meeting (30 mins – 1 hrs max) is setup 1-2 Sprints before a feature is expected to go into development.
1 Developer + 1 QA are identified and invited to the meeting. These are expected to be the individuals who will develop and test that feature.
The Business Analyst begins the meeting by introducing the feature to the Amigos. Why is the feature needed, is it like anything they’ve done before, what should it look like on the site?
The Business Analyst presents the requirements (prepared prior to the 3 Amigos) – these are reviewed by the Amigos who provide feedback. The requirements should be updated in the session until the requirements are deemed “Ready for Dev”.
The Business Analyst will then present the test scenarios (prepared before the meeting) – these are also reviewed by the Amigos. Feedback is incorporated until it is agreed that the test scenarios cover the feature’s expected behavior - this ensures good test coverage.
The feature/specification is now “Ready for Dev” – it has been accepted by the developer and QA.
Developer – asked to identify any tasks that need to be done pre-development e.g. do they need access to an endpoint, do they need to see variants of the visual design? These tasks are assigned and put on the current Sprint board.
QA – asked to identify any tasks that need to be done pre-feature testing e.g. do they require access to a system, do they need mock data? These tasks are assigned and put on the current Sprint board.
Estimate: the Amigos should have a common understanding of the requirements and the test scenarios (the "feature"). This is a good opportunity for the developer and QA to provide estimates.
Lessons we have learnt:
The developer and QA involved in the 3 Amigo meeting should be the individuals who will develop and test the feature. We have explored the idea of “any developer/QA can be involved in the 3 Amigos and any developer/QA can then pickup the feature” – however we have learnt that maximum benefit comes from the Amigos being involved in a feature until its completion.
The requirements and test scenarios should be maintained in a place where everyone has access. This gives individuals/stakeholders (even non-Amigos) VISIBILITY of the requirements and tests.
What language should be used for requirements and test scenarios? Technical? Business? Plain English? We have found that DOMAIN language is the most useful … if you work in banking than all 3 Amigos should know what a derivative is - but not everyone is expected to know what a cron job is. If in doubt – maintain a glossary of terms.
Challenges:
For the BA: although the BA still tacitly “owns” the requirements – part of the collaborative 3 Amigo process is a shared level of ownership. This can be difficult for a BA - as requirements are one of the main BA deliverables.
For the Developer: there may be some resistance to reviewing requirements/test scenarios as these are “non–development activities”. In our experience the 3 Amigos process enables the developer to have greater visibility of the requirements, provide technical feedback and convey challenges/blockers.
For the QA: similar to the BA – they may need time to adjust to the test scenarios being under common ownership.
For the Product Owner: the Product Owner isn’t an Amigo. The process assumes that the BA represents the Product Owner/stakeholders. Once the requirements and test scenarios have been through the 3 Amigo process– it can be worth re-confirming them with stakeholders.
For the PM: the 3 Amigo process limits what a PM can put into a Sprint – features are pulled into a Sprint by the team and not pushed by the PM. The BA can begin to take on some traditional PM duties: task breakdown (tasks are identified in the 3 Amigos), estimations (developer + QA estimates are provided in the 3 Amigos), limited Sprint planning etc.
For the Agile enthusiast: to be a fully iterative process there may be “pre amigo” meetings – and complex features may require several sessions.
Author: Ryan Hewitt, Senior Business Analyst
Ryan Thomas Hewitt has over 5 years business analyst experience working for blue chip companies in India, Germany, USA, Italy and UK. Ryan holds certifications in scrum, lean, ITIL, change management and NLP.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: