What was the problem?
In order to encourage the incorporation of Agile practices into our software project, we adopted the roles and artifacts of Scrum. Features were assigned to iterative sprints, the product owner maintained a prioritized product backlog, and the ScrumMaster facilitated daily stand-ups and fortnightly show-and-tells.
But our team encountered an interesting challenge: How do you get the various roles in a Scrum team to have a common understanding about a feature?
- Business analysts talk in terms of requirements/acceptance criteria.
- Developers talk in terms of code/unit tests.
- QA members talk in terms of scenarios/test cases.
Our team discovered that there was a need to facilitate shared understanding and shared vocabulary about features across the Scrum team. Otherwise there was:
- Confusion (What behavior is required for the feature to be considered complete?)
- Complexity (When a developer updates the dynamic index code, will this affect the test scenarios for the customer landing page?)
- Duplication (Will unit tests cover this behavior or does it require manual testing/UAT?)
How did we solve the problem?
We introduced a process into our Sprints called "The Three Amigos." Essentially, this is a meeting during which the business analyst (BA) presents the requirements and tests for a new feature. The Three Amigos (BA, developer, and QA) discuss the new feature and review the specification. The aim is to create a common understanding and shared vocabulary across these individuals. The QA and developer also identify missing requirements/edge cases — these need to be defined before a feature is considered ready for development ("ready for dev") and can be assigned into a sprint.
The benefits we gained from introducing the Three Amigos process were:
- Shared understanding of the requirements across the Scrum team
- Shared understanding of the tests across the Scrum team
- Consensus about whether a feature was specified sufficiently (and therefore whether the feature was ready to go into a development sprint)
What lessons did we learn from the Three Amigos?
- By only accepting features that have been Three Amigo'd, features are pulled rather than pushed into a sprint.
- Requirements and tests need to be visible and understandable to all members of a Scrum team.
- A shared sense of requirement and test ownership facilitates quality specifications.
- The developer and QA involved in the Three Amigos meeting should be the individuals who will develop and test the feature. The maximum benefit comes from the Amigos being involved in a feature through its completion.
- When specifying a feature in the Three Amigos, rather than using technical language (e.g., the JSON endpoint) or plain English (e.g., the financial instrument), we decided to use domain language. If the team works in banking, for example, then all Three Amigos should know what an OTC derivative is. This keeps the entire team aligned with the business. If in doubt, maintain a project glossary.
- To embrace the iterative approach of Scrum, there may need to be several Three Amigo sessions in order to perfect a specification.
- Initial resistance to reviewing requirements/test scenarios may be encountered from developers, as these are considered "nondevelopment activities." However, it is our experience that the Three Amigos process enables the developer to have greater visibility into future requirements, provide technical feedback, and convey challenges/blockers.
- The process assumes that the BA represents the product owner/stakeholders. Once the requirements and test scenarios have been through the Three Amigos process, it can be worth reconfirming them with stakeholders.
Want to introduce the Three Amigos?
Below is a copy of our crib sheet. Based on several iterations, this is the Three Amigo process we now adhere to:
- 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.
- The BA should begin the session by introducing the feature to the Amigos. Why is the feature needed? Is it like anything they've done before? Is there a visual design?
- The BA should also present the requirements (prepared prior to the Three Amigos meeting). These will be reviewed by the Amigos, who will provide feedback. The requirements should be updated in the session until the requirements are deemed ready for developement.
- The BA should then present the test scenarios (prepared before the meeting). These are also reviewed by the Amigos. Feedback is incorporated until there is agreement that the test scenarios cover the feature's expected behavior. This ensures good test coverage.
- The developer is asked to identify tasks that need to be done before development. For example, 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.
- The QA is asked to identify tasks that need to be done before feature testing. For example, do they require access to a system? Do they need mock data? These tasks are assigned and put on the current sprint board.
- Regarding estimating, the Amigos should have a common understanding of the requirements and tests. This is a good opportunity for the developer and QA to provide estimates.
- The feature/specification should now be designated as ready for development. It has been accepted by the developer and QA and is ready to be assigned to a future development sprint.