The “Tea Bag Approach” to Agile Business Analysis, otherwise known as “Feature Injection” or “The Cotswold Way” is an approach that allows us to slice requirements by value, and using examples to provide specifications that can be automated (i.e. test automation). This page provides links that point to the articles/blog that form the ideas incorporated within the approach. It also provides references to books where this ideas are expanded and supported by examples and tutorials to help people better understand the approaches.

The “Tea Bag Approach” (described here) has a number of steps. The fundamental approach is to work backwards from Outcomes -> Outputs -> Process -> Scenarios and then Inputs or OOPSI as coined by Jenny Martin. A more thorough description of parts of the process are described by Kent McDonald in “Beyond Requirements”.

  • TEA BAG: Every project starts with a tea bag. The person asking for the project describes a tea bag which is a solution rather than the description of the outcome (opportunity to be exploited, or the problem to be solved). In addition, the solution is only partial rather than the whole solution.
  • CUP OF TEA: The first step is to create a hypothesis about what the Output or total solution should be, otherwise referred to as the Cup of Tea. The “Cup of Tea” or output is found using “five why’s” to move the discussion toward the output of the system rather than focusing on the details of the inputs to the system required to provide the tea bag. This is a discussion with an SME or Customer. This output is normally a sketch on a piece of paper, a lightweight prototype in Excel/Powerpoint or possibly even a data extract. It is the output of the system. If the output of the system is data fed to another system, you will probably need to understand the output required by the user of the downstream system unless the BA/PO of the downstream system has provided you with the output they need which is the input to their process i.e. they have completed their own OOPSI process.
  • USER NEEDS: The next step is to understand why the customer/user NEEDS the output they have requested. This introduces us to the rick subject of User Needs in User Experience design. There are many books on the subject. A particularly popular approach to understanding user needs is Clayton Christenson’s “Jobs to be done” which phrases the need as “What job is to be done by the output” which then allows the discovery of other solutions that could perform the same job. There are many excellent references on this subject, here are a couple of basic introductory ones to act as bread crumbs to get your journey started.
  • SEGMENT DEFINED BY NEEDS: Once we understand the needs, we then focus on the segment of people defined by the needs. This is not the same as “roles” or “user” but rather the segment of people that have the need. These segments are often described as personas to help UX designers better connect with them.
  • BUSINESS VALUE: This is the value delivered to the business by satisfying the needs of the segment of users. There are many excellent resources on this subject which includes Metrics and OKRs. The Metrics Hierarchy approach adopted at Skype is particularly useful. The key point is that succes for small investments by POs during a sprint will be measured in metrics other than just profit, instead they will use metrics like number of customers, activity, satisfaction, lead time. Given how badly this subject is handled in most companies, this is a good place to start:
  • DESIGN BRIEF: The combination of the User Need, Segment and Business Value forms the design brief. A common format for describing the design brief is
    • IN ORDER TO <deliver business value expressed as an improvement in a Metric/OKR>
    • AS A <Segment defined by need>
    • I WANT <Vague description of solution>
    • SO THAT <it satisfies my user need>
  • SLICING STORIES: The only way to slice stories is to slice the design brief into two or more parts. Slicing any other way results in building a partial solution that does not deliver any value. It is only if a deliverable provides value for a segment of users that it will be used and the product owner can get feedback to help them adjust the next investment that they make. As the subsequent design goes the process of elicitation, further opportunities to slice the requirements will be presented. Slicing requirements is explained in:
  • There are many different ways to come to the design brief, not just the process described above. However, the design brief is necessary before you can start on the design. This is often a control point in product owner processes.
  • DESIGN: There are many great books on UX Design. In financial systems, the design is normally the output (report, screen, database, API, XML) that the user consumes. A key aspect of the design is testing of the design with its intended users, or user testing. This is covered in the Marty Cagan book above. A key thing to look for in the design is that it does not require the need to “fix the design in the user” as Kathy Sierra refers to products that need training to enable people to use them because they are designed so badly. This interaction with the intended user of the design is one of the most important phases and tends to generate a lot of insight and feedback. Be prepared to revisit the design brief and design as a result of the insights and feedback.
  • THIS IS THE POINT WHERE THE PROCESS TRANSITIONS FROM PRODUCT MANAGEMENT TOOLKIT TO THE BUSINESS ANALYSIS TOOLKIT.
  • DATA MODELLING: Data modelling is a fairly straight forward process once the target output is known as described in the information smells process. This process allows us to efficiently create a detailed business model of the system required to deliver the design that hopefully satisfies the needs of the segment of user affected by the need. Although this abstract model is useful for architectural discussions, it is not very effective for communication with users and stakeholders. For that, examples will be needed.
  • ARCHITECTURE: At this point, product owners and architects can come together the agree on the best approach to delivering the design. They may decide to adopt the future or state architecture which might take longer to deliver, or they may adopt a faster solution that does not enable the future state architecture and creates technical/architectural debt that the product owner has to commit to paying down. Part of the architecture design process is to identify the source of all data needed in the system, in effect the inputs.
  • EXAMPLES: Comprehensive sets of examples will be used to provide the specification for the system. Examples are preferred to abstract models as they form a better, more stable and understandable, basis for conversations with all involved, especially not technical people. Some examples will be discovered as part of creating the business (Data) model using the information smells process. Others will be discovered by the “Three Amigoes” (Product Owner/Business Analyst, Quality Analyst, Developer) as they create the examples that form the specification. The examples will often end up as automated tests in one of the automation frameworks like cucumber. The following books are useful references:
  • BEHAVIOUR: The behaviour of the system can be described by the Given When Then framework which creates examples that can be used in test automation frameworks like Cucumber. This bahviour includes describing the processes including input screens that are needed to get data into the system. The following books are useful references:
  • USER STORIES: Once the examples of data required to drive the design (inputs) and interactions with users and other systems (behaviour) are known, the three amigoes can slicing the requirements into appropriately sized stories for the development teams. The following are useful references: