Methodology Bits: The Triad Meeting

User Stories are placeholders for a conversation about the expected behavior of the product.

Goal

To get a common understanding of a User Story to develop, the team needs to refine the story. However, some technical constraints, feasibility concerns, development directions are better discussed, and possible misunderstandings and confusion are better cleared up early on, providing a well-thought-out story delivered for refinement, while setting a reasonable limit on the number of people involved in discussions about the User Story.
A Triad meeting is an on-demand meeting, called together by the Product Owner, to clarify raw User Stories and create a shared understanding of the intent, scope, and technical details of the work. The concept of a Triad meeting is to balance between no collaboration between people with different perspectives and involving an entire team in discussing all the details of a User Story.
The result of a Triad meeting should be a clearer description of the User Story, usually in the form of acceptance criteria and/or scenarios and examples. This way the User Story transitions from its Raw state to its Refinable state.

Format:

When?

A Triad is an on-demand meeting, the Product Owner calls for one any time during the Iteration whenever a User Story is getting close to starting delivery shortly.
The meeting is timeboxed to 25 minutes, but it should usually be shorter.

Who Attends?

The Triad is called together by the Product Owner; and is attended by some members of the team that hold different perspectives, along which user stories are examined. These perspectives include but are not limited to:

1. Business: Representing the desired outcome of the User Story. Usually embodied by the Product Owner, a Business Analyst, or an End User. The most important question in their aspect is: “What problem are we trying to solve?”
2. Development: Representing the Development Team’s opinion on how to deliver the outcome that the business desires to have. Usually embodied by a developer or an architect. The most important question in their aspect is: “How might we build a solution to solve that problem?”
3. Quality Assurance: Representing the edge cases, negative paths, “what if”-scenarios. Usually embodied by a tester. The most important questions in their aspect are: “How can we validate that this solution is correct? How can we make sure that this solution does not contain user paths that were not considered beforehand?”
4. User Experience: Representing the user journey and the user experience. Usually embodied by a UX Researcher or UX Designer. The most important questions in their aspect are: “How could the End User walk through this story in the easiest, most comfortable, and most intuitive way? How should the visuals look for this story?”

This list can – and sometimes should – be further extended depending on the User Story discussed. It is common to invite e.g. operations people, other stakeholders providing further information, technical writers, etc. However, it’s also an essential goal of the Triad to keep people discussing a User Story as low as possible without sacrificing the usefulness of the discussion – so involving multiple developers, or a whole team is usually not recommended.
As the Triad is an on-demand meeting, it should be self-organizing. The Product Owner should share the raw User Story (containing a title and a few sentences of description) that will be the topic of the meeting in a common channel, and people with the necessary knowledge should flock to take part in the meeting. There should be no official invitations, no recurring meetings, no “people who usually go to Triads”.
People having the most information about the given topic should attend if it is possible, as the information available for the team should be represented in planning the User Story. However, it is also an option to come up with questions during the meeting that other team members might be able to answer, and either clarify these details after the Triad or have a second round later.
It should also be noted, that attending a Triad about a User Story carries no obligations regarding taking part in the development of that user story – it is possible that the developer attending the Triad won’t be working on developing the User Story, or the tester attending the Triad won’t be testing it. They are just the arbiter of the team knowledge and representative of their perspective.
Having a formal facilitator is not necessary for a Triad meeting, but – especially early on – it may help the team to stay focused, on topic, and not get lost in detail.

How does the process look like?

At a Triad meeting, people representing the different perspectives should collaborate to refine, clarify, or validate a user story; to define what to develop, how to develop it, and how to verify when it is done correctly. The process is often called Example Mapping.
The input of the meeting is a raw User Story, with a title and a few sentences of description. The Product Owner describes the story, the others ask questions and make suggestions until they feel they can answer the question “How will I know when this is accomplished?” from the perspective they are representing at the meeting. An important rule of the Triad is that there are no stupid questions. If someone feels the need for clarification, there is a need for clarification.
The information surfacing during the Triad is noted down in the form of three different artifacts: rules (preconditions and informal acceptance criteria), examples (scenarios and the expected behavior of the system in those scenarios), and questions (things that need to be clarified or validated before the development can begin, or assumptions made explicit).
Rules should be short sentences that describe preconditions and general constraints about the feature. Most of the acceptance criteria should be expressed by these rules.
E.g.; “a refund can only be processed in 14 days after the purchase”, or “a password must contain a capital letter, a number, a plot, a protagonist with some character development, and a surprise ending”, etc.
Examples should be scenarios, describing a user journey through the story (personas come handy here). For each rule, there should be one or more examples to illustrate it.
People frequently find the “Friends episode naming pattern” helpful in creating examples: all example names should start with the phrase “The one where…” and continue with a single sentence description of the situation. Then the examples can be shaped into a precondition-action-postcondition format (using the given-when-then syntax might be useful, but not necessary at this point), but they should not be full-fledged acceptance tests (formalizing those with all the Triad members present would probably be a waste of time).
E.g.: “The one where the product was bought 15 days ago: Given the product was bought at 12:00 on the 1st of May, When the customer returns the product at 13:00 on the 15th of May, Then the refund can be processed”, or “The one where the password is a common word: When the password is >>tomato<<, Then it should be rejected”, etc.
Questions are known unknowns in either the requirements or the development details of the story. These are questions that nobody attending the Triad can currently answer. These represent the team’s current knowledge horizon and signal some further work before the story can be developed (but it should not always block the story from progressing into a Refinable state).
Noting questions and assumptions is important, as being noted transforms them from unknown unknowns to known unknowns. However, it takes some practice and self-control to make a note of gaps in team knowledge, form questions about uncertain points and move on with the discussion, but it is an important aspect of a Triad: the goal is not having an exact definition of the story, but rather mapping out the team’s understanding of the story. Sometimes a User Story might require multiple Triad meetings to get ready for refinement, with various members doing their homework in-between those meetings.
E.g.: “What happens if the customer forgot to bring along the receipt?”, or “Should common words with common replacements, such as >>t0m4t0<< be accepted?”, etc.
The output should be a healthy mix of rules and examples, with a stray question or two. If the number of rules and examples is too high, then it might be an indication that the User Story should be split up to multiple smaller User Stories. If there are lots of questions, then the story needs more clarification – there might be some stakeholder input, Product Owner homework, or user research missing, or the developers should execute a spike to test something.
This collectively leads to a shared understanding of the intent and the technical details of the work, and a clearer description of the User Story.
At the end of the meeting, the participants cast a vote with a fist of five to express their confidence about the story being ready for refinement.

Triad Antipatterns

Regularly scheduling Triad meetings and treating them as a ceremony – Triads should be short, on demand, irregular meetings. Resist the temptation to schedule them and invite people to them. If a role is not filled until the start of the meeting, shout out in a common channel about still needing a tester/developer/UX expert for the Triad.
Limiting the meeting to only the perspectives mentioned above – if there are other stakeholders interested in the discussion they should also be able to join.
Expanding the meeting to the whole team – the Triad is explicitly there to limit the work to as few people as needed. People with no additional information should work on things they can add value to instead of being present at a Triad. One person representing each perspective is usually enough, and it’s very rare that two developers or two testers need to be present.
Writing formal acceptance tests during the Triad – sometimes it might be useful, but it is a waste of group time. The examples should be a good enough reminder for formal acceptance test creation later.
Being stuck at questions – this one is difficult, but to keep the Triads short, it’s important to realize that there are questions that the people present simply cannot answer. It is fine – the Triad is not a problem-solving meeting, and there is nothing wrong with noting down uncertainties. If a question cannot be answered at a Triad, just capture it and move on with the discussion.