Having read the article by Ryan Thomas Hewitt
about using a process called “Three Amigos
,” I felt motivated to share my thoughts on it, how we are using it, and how we have included some other things as well.
As Ryan states on his article, the Three Amigos is used to help the Scrum team have a shared understanding of the requirements, have a shared understanding of the tests, and reach a consensus about whether a feature was specified sufficiently (and therefore was ready to go into a development sprint).
How it started
One of our developers brought up the idea of the Three Amigos practice, having heard about in a community session. Then after reading the article and understanding the purpose of it, we started doing it in our next sprint. However, we made slight changes that we felt would make more sense for our team.
How we use it
We deviated a little bit from Ryan’s approach in these ways:
- When the sprint planning is complete and the team has its sprint backlog, we return to our desks to start working on the product backlog items (user stories) with all the items in the “To Do” column.
- When a developer is about to start working on a specific user story, he or she calls for the tester and the BA (acting as a proxy product owner) and they have the first Three Amigos session.
- Once everybody is on the same page and has that shared understanding that this process brings, we move the item from the “To Do” to the “In Progress” column, and the work on the user story begins.
- After coding and testing is completed, a second Three Amigos session is called with the same people who worked on the user story.
- If everything is OK, the feature/functionality is working as expected, and tests are running green and confirm that the developed item is not breaking the build, then the piece of code is merged into the master branch and the item can then be moved to the “Done” column.
How we improved it
By having a second session, we found reassurance that what the BA requested, the developer coded; and that the tester created the tests based on the scenarios identified as acceptance criteria for the user story. It works as a way to sign off the items we have in the backlog before going in for the sprint review.
This is also helpful because in our context, the BA usually has sign-off authority and can be seen as a proxy PO. It is not the desired end state, but while we don’t have the PO signing off the user stories, this helps us have the assurance of the work.
But what about the Bandits?
We then introduced another session called Bandidos (Bandits), which usually runs before sprint planning. Since we were working with more than one Scrum team, we felt that it was necessary to do a split of the work before the teams went for their specific ceremonies. So the Bandits session is run before the sprint planning in order to mark a separation of the work for each team (let’s say Team 1 and Team 2). Once the work is split (usually at an epic level), we then run our normal Scrum ceremonies to make sure that the backlog is prioritized, in a ready state, properly refined, estimated, and good to go!
In this session we usually have a BA, a developer who acts as a lead, user experience and user researchers, and a lead tester. So the Bandidos (or “bad guys” -- ha) try to prepare everything and make sure that the next pieces of work are in good shape for the teams to pick up in their regular ceremonies.
The Amigos and Bandidos are helping us make sure we are delivering what our PO requests and organizing the backlog prior to the sprint starts. I would like to hear your comments and suggestions about how we can make it even better, and also how you may have used this process in your projects.