The Three Amigos and Backlog Refinement for a Continuous Flow of Value
The Why
The Three Amigos and Backlog Refinement are very useful collaboration techniques to ensure the user stories are more consumable that leads to a continuous flow of value. The Three Amigos conversations help to front-load quality/ testing at the start of the software development lifecycle, instead of the traditional approach of keeping it at the end.
While working with several agile teams, I have seen that there is a lot of confusion about how to get these techniques right and they often get mixed up. The Scrum Guide, too, doesn’t say much about the Backlog Refinement, and there is no mention of the Three Amigos. So here is my attempt to declutter the two and share some approaches on how we could adopt and get the most from them.
Cut the clutter — Product Backlog Refinement and the Three Amigos
What is Product Backlog Refinement?
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work. — The Scrum Guide, 2020
👆 That is all that the latest Scrum Guide talks about the refinement process.
To know more about the process, I highly recommend reading this 🔗 article, written over a decade ago, that describes the D.E.E.P (i.e. Detailed appropriately, Estimated, Emergent and Prioritised) attributes of the product backlog quite beautifully.
Why should I refine the backlog?
My short answer to that question is to “Manage Flow”.
Refining the backlog means to prioritise the backlog, add the necessary details, i.e. the items higher in priority are typically more detailed, smaller and consumable. Rightly sized and sliced (read about INVEST). Such a backlog will enable the engineering team to deliver a continuous flow of value. In other words, the top of the backlog meets the “Definition of Ready”.
As we go down in backlog, it is populated with relatively lower priority items, the detailing is lesser, the items are more abstract and the size of them keeps getting bigger, which is all OK!
In Scrum, the top of the backlog, would then, be ready to be pulled in the upcoming Sprint during the Sprint Planning meeting. In Kanban, we move the top of the refined backlog to a queue (usually called “Ready for Dev”), which has fleshed-out user stories, meeting the definition of ready, primed to be actioned upon by the engineers.
Refining (or grooming) the product backlog, is also an opportunity to build alignment in the team. It is a chance for the Product Owner to explain the business value and purpose of the upcoming work to the rest of the team, and such conversations lead to a shared understanding.
So how do I refine the backlog?
While there are several ways to refine the backlog, I think there are two useful approaches that you could experiment to see which works better for your context.
Involve the entire team in the refining activity. There are several benefits of refining the backlog collaboratively, involving the whole team. It dissolves the boundaries between roles and brings business and tech capabilities closer. Gives an opportunity for the Product Owner to build alignment with the rest of the team. The team fleshes out the user stories together which leads to a shared understanding and ownership from the start of the process. This approach reduces handovers and the risk of information barriers in the team.
An alternate approach — start with a smaller group who work on refining the backlog, and at a later time share the outcome with the rest of the team to build alignment. This smaller group can analyse requirements from different perspectives, create user stories, add details to them such as a description, test scenarios and acceptance criteria. The refined user stories can then be shared with the rest of the team, and the sizing and prioritisation activity happens with the rest of the team to build alignment with everyone else.
The Three Amigos
The Three Amigos is this smaller group that includes the 3 core capabilities i.e. product ownership (or business analysis), development and testing who collaborate to exchange different perspectives of business, engineering and testing that ensures the team builds the right thing and builds the thing right.
The product owner (or business analyst) discusses the user needs and clarifies using examples. The developer and tester understand the user stories which are further sliced to make them more consumable. High level scenarios on how to test the user stories are discussed. Missing scenarios are identified and acceptance criteria are added for each testing scenario. All of this, before a story is developed.
Front-load Quality
From specification perspective, the Three Amigos are the first steps to #ShiftLeftTesting. Articulating clearly how something would be tested before it is actually developed, not only improves our development process, reduces handoffs and time to test, more importantly, it is a paradigm shift from the traditional way of thinking about the testing, as it front-loads quality at the start of the software development lifecycle, rather than at the end.
The Frequency of the Backlog Refinement and the Three Amigos
Both these collaboration techniques are ongoing activities. How often and for how long depends on your context. My experience says that shorter sessions spread across are more effective than weekly or fortnightly sessions. One can even try meeting for a few minutes at the end of every standup.
Three Amigos for the advanced
Once we’ve got our Three Amigos to meet often enough, we usually see much better user stories entering the development stage. Such stories are detailed appropriately, have the test scenarios and acceptance criteria well defined before starting development, and give good visibility to the developers on what to test their code against. This leads to an improvement in the overall quality of the product.
Pro-tip 1: Do not stop there! The Three Amigos has now become our way of working. That is how we engineer requirements. It has become a habit. Nothing, at this point, should stop us from involving other capabilities to join our Three Amigos meetings. If capabilities such as the UX, or the architecture or devops did not exist already, invite them to the Three Amigos conversations.
Pro-tip 2: Take it to the next level. Occasionally, we invite our users to those conversations. Not a lot can match upto the benefits of involving users or customers earlier, to have feedback opportunities even before something is built. How about that? Build the right thing, remember! And build better bonds with our users and customers.
Pro-tip 3: And why to stop even there? The Three Amigos can meet right before the developers are about to pick up a new user story to develop. Getting the user story 3 amigo-ed before we actually start to write code will go a long way in front loading quality in our software. Though I don’t encourage hand-offs to a separate QA stage, but in your context, if there is a QA stage after development, then before the handoff, it is a good time for the 3 Amigos to see the working software. This is a useful time to poke holes in the implementation, before the story is actually handed off to the QA. This will reduce the risk of the story going back-and-forth between development and QA, as gaps are identified earlier at this stage.
Summary and some further reading
While I hope this article helped to introduce you to the Three Amigos and the Backlog Refinement, and if you are already doing them, I encourage you to experiment with some new approaches to get even more from them. The principal benefit of these techniques is to assist flow. And the key is to start where you are and improve as you go along. Don’t worry about scheduling formal meetings that look like an overhead and takes too much time in the diary, you can simply start with some casual conversations over coffee and some sticky notes, that brings these complementary capabilities together.
Some advanced teams are utilising the Three Amigos sessions to specify the scenarios to test the behaviour of the system, by writing them in a natural language that utilises the Given-When-Then format. This is an approach developed by Dan North and Chris Matts as a part of Behavior-Driven-Development (BDD). This Gherkin syntax format fits seemingly well with various testing frameworks such as Cucumber, JBehave, FitNesse etc. These are good topics for advanced reading and test automation enthusiasts.
